Move the cache first

The visible work on a cloud migration is the application tier. You can draw it. You can count the boxes. A steering committee can ask whether those boxes are on Google Cloud yet, and you can give them a number. I did that at Moneycontrol. It was the wrong number.

The constraint was never the servers. It was the cache that kept a market-moving story up when the origin could not, and the warehouse that stopped the business asking the production database a question it was not built to answer. Until those two moved, every cutover plan was a story about servers that still depended on the old building.

What I got wrong

I sequenced for what photographed well. Application servers first, because that is the sentence people understand. Caching and in-memory layers, and the warehouse that replaced batch reporting, came later — as if they were finish. They were the reason a no-window migration was possible at all.

A newsroom does not give you a Saturday. A market-moving story is exactly when you cannot be down. If the cache is still pointed at the old origin, you have not migrated. You have two origins and a prayer.

What I would do on Monday

Move the cache first, and prove it can miss without taking the site with it. Move the warehouse next, and stop the reporting jobs from leaning on production. Only then walk the application servers across. The board will ask why the boxes have not moved. Tell them the boxes were never the constraint.

Traffic went from 20 million to 80 million a month on that platform. That number is not a migration metric. It is what happens when the thing that absorbs a spike is already on the other side of the cut.