Migrations are product work: cloud, payments and CMS

The short version

• A migration has customers. Name them before you plan anything.
• Define "no worse" first. Parity is the first release; improvement comes after.
• Sequence by risk and reversibility, not by what looks tidy on an architecture diagram.

I've been responsible for three migrations in three industries: moving Expedia's infrastructure from traditional data centers to AWS, moving Maqsam's payments to Stripe as its primary gateway, and modernizing Al Jazeera's CMS into a unified headless platform. The technology was different every time. The reasons they succeed or stall were remarkably similar.

A migration has customers

It is tempting to treat a migration as an engineering project with a product manager attached. I find it works better the other way round. Every migration changes someone's day: the engineers who run the system, the support team who answer questions, finance who reconcile the numbers, the editors who publish, and the end users who just want things to work.

For each group I write down three things: what they do today, what must not break, and what gets better. That list becomes the success criteria and the communication plan.

Define "no worse" before "better"

Before you migrate anything, measure the baseline: reliability, failure rates, speed, cost to operate. Then make parity the first goal. A migration that cannot show it is no worse than what it replaces is not ready, however elegant the new design is.

On the Stripe migration at Maqsam, the goals were payment reliability and a cleaner prepaid credit flow. A reliability goal only means something if you can see how payments fail today, so a clear failure baseline has to exist before the cutover, not after it.

Sequence by risk and reversibility

Architecture diagrams suggest an order that is tidy. Risk suggests a different one. I prefer small slices that carry real traffic, with every step reversible and a rollback that has been rehearsed. Keep both systems alive for as long as you need to. And don't promise a final date until the first slice has run in production.

Payments deserve extra care

When money moves, trust is fragile. The questions I'd always ask on a payments migration:

• What are the failure types? Declines, technical errors and abandoned checkouts need different fixes, so separate them.
• What are the balance edge cases? With prepaid credit: top-ups, partial failures, retries, refunds.
• Can a retry ever charge twice? Idempotent requests are the answer.
• Who reconciles the numbers? Finance should see the new reports before cutover, not after.
• How will you know within minutes if something is wrong? Monitoring belongs in the first slice.

Cloud migrations are about the people who run the system

Moving from data centers to AWS is often described in terms of efficiency and reduced overhead, and those are real benefits. But they only arrive if the teams who operate the system are ready: new skills, clear ownership, new ways of working. I treat those teams as the users of the migration and plan for their adoption as carefully as I would for a customer-facing launch.

CMS migrations are workflow migrations

For a newsroom, the editorial workflow is the product. A headless platform lets one content system serve the website, mobile apps and streaming, which is a real strategic gain. But it only counts if the day-to-day experience for editors stays fast and familiar.

Much of the work is coordination: vendors and technology partners need clear integration contracts, and performance, stability and scalability need owners. I measure the migration by whether publishing gets easier, not by whether the new architecture is clean.

Communicate like it's a launch

Write release notes for internal users. Hold office hours. Keep a visible status. Say plainly what changes for each group and when. In my experience, much of the friction in a migration comes from surprises rather than from the technology.

The measure of success

The best migrations are boring. Nobody remembers the cutover; they notice, months later, that things are faster, steadier or cheaper to run. That is the outcome to design for, and it is a product outcome.