You have twelve weeks and a large estate. Which replatforming changes do you make and why those?

What is being tested

Whether you prioritise by operational burden removed per unit of effort rather than by what is technically interesting.

The prioritisation

1. The component consuming the most operational time. Usually a self-managed database or message broker. Moving to a managed equivalent removes patching, backup, failover and a large share of on-call burden — the largest single return available.

2. The component with the worst reliability record. Incident data identifies it; the fix frequently is the managed version.

3. The largest cost line where right-sizing or a tier change applies. Configuration changes with immediate effect.

4. The dependency approaching end of support, because the deadline is external and not negotiable.

What to explicitly not do

Anything that works, is supported, and rarely changes. Age is not a defect, and modernising a stable low-change component is frequently the least valuable work available. Twelve weeks spent there is twelve weeks not spent on the database that pages someone weekly.

The traps

Scope creep into refactoring. "While we are here" turns a six-week replatform into a nine-month redesign, which is how these programmes lose their funding. Hold the line: replatforming changes the platform, not the application's structure.

Managed service failure modes not read. Failover times, maintenance windows and connection limits are documented behaviour, and the application must tolerate them. A managed database failing over for 40 seconds during a routine patch is normal; an application that errors throughout has a resilience gap, not a vendor problem.

Connection limits, particularly moving to serverless or high-replica topologies. A connection pooler is usually mandatory and is discovered late.

Behaviour differences between a self-managed engine and its managed equivalent — extensions, versions, configuration flags. Verify before committing.

What a strong answer adds

Measuring the outcome in operational time recovered, not in components migrated. "On-call pages from this tier fell from eleven a week to two" is the argument for the next phase; "we migrated fourteen components" is not.