I recently upgraded an AWS Lambda function from Node.js 18 to Node.js 24. It was a straightforward migration on paper, but like most upgrades that touch deployment pipelines, there were enough gotchas to warrant some careful planning. Claude’s planning mode turned out to be really useful here. Not just for generating the plan, but for the discipline it forced into the process.
The Setup
The function is a Garmin Activities Lambda that processes data and writes to a database. It’s part of a system I rely on, so breaking it felt like a real risk. I needed to be deliberate about the approach. No sneaking in refactoring. No architectural changes. Just the Node version bump.
I told Claude to focus on three things. One: be very specific about the scope. Just the migration. Two: follow standard deployment practice. Start in lower environments, move to TEST, then to PROD. Three: have tests at each stage that actually confirm things work.
Claude came back with a solid plan. Risk assessment looked good, mostly because the dependencies were already compatible. Rollback was simple if needed. There was a testing checklist covering all the obvious things.
But here’s where I caught something Claude missed.
The Test That Wasn’t Complete
I’d worked through the deployment testing with Claude the day before. Then the next morning, when Claude generated the testing checklist for this migration, it forgot about end-to-end testing. It included things like “Lambda function shows runtime: nodejs24 in AWS Console” and “Activity insertion works via API Gateway,” but it was basically checking if the Lambda could be reached, not if it actually worked correctly.
I asked Claude about the gap. The answer was useful: the session was running low on context. It had been a long conversation with a lot of back and forth about different deployment scenarios and environment setup. The earlier work on post-deployment testing wasn’t fresh in memory.
That turned into a good learning moment about how to work with Claude more efficiently. Not a complaint about Claude, really. More like learning the rhythm of the tool.
What I Actually Learned
The practical stuff is obvious. Node.js 24 is backward compatible with 18. The deployment script needs a single line change. The tests pass. All straightforward.
But the more useful insight was about communication. When I asked Claude why it skipped the end-to-end testing, it gave me specific guidance on how to direct requests better. Instead of asking for “test the deployment,” I should say “verify end-to-end” or “confirm database writes.” Specificity cuts through a lot of noise.
It also highlighted something about session management. Long conversations accumulate context weight. At some point, earlier decisions and work get buried. If you’re working on something complex and you notice yourself repeating context, starting a new session is often the right move. Not because Claude forgot, but because you’re burning tokens rehashing ground you’ve already covered.
The other takeaway was about token efficiency. I could have pointed Claude to specific files instead of asking it to explore the codebase. “Check the deployment script” beats “figure out how we deploy things.” It sounds simple, but it’s the difference between a three-minute task and a ten-minute one.
The Migration Itself
The actual work was clean. One environment variable change, everything gets tested, everything passes. Node.js 18 reached end of life back in April, so this was overdue, but better late than waiting for a security issue you have to patch in a rush.
Worth noting: Node.js 24 is supported until April 2027. There are future optimizations sitting in the backlog now. Update the TypeScript types. Bump the ES target. Maybe add an engines field to package.json so future developers don’t accidentally deploy this on the wrong runtime. But those are separate work. You do one thing at a time.
Moving Forward
The migration is live in production. The tests are solid. And I’ve got a clearer sense of how to work with Claude on this kind of task. Be specific about scope. Point it at the files you know matter. If the conversation feels long and you’re repeating yourself, start fresh. And when something gets missed, ask why instead of just fixing it. That’s where the real learning lives.