The risk in a cloud migration almost never lives in the destination. Modern platforms are mature, well documented, and forgiving. What breaks migrations is the cutover itself, the dependencies nobody wrote down, and the data that is subtly wrong in ways the old application quietly learned to tolerate. If you are anxious about a migration, point that anxiety at the move and the data, not at the new platform.
Why the platform is rarely the hard part
Teams spend most of their planning energy on the target: which services to use, how to size them, how to lay out the network. This work matters, but it is the part with the most documentation, the most examples, and the most vendor support. It is knowable in advance. You can read the manual. You can build it in a test environment and see it work.
The hard parts are the ones you cannot fully see until you move. They live in the seams of the system you already have, not in the system you are moving to. This is why migrations that looked straightforward on the architecture diagram still go sideways on the night.
Undocumented dependencies
Every system of any age has connections nobody remembers. A batch job on a forgotten server that writes a file another process depends on. A hard-coded IP address. A firewall rule that has quietly load-bearing status. A report that only works because it reaches directly into a database it was never supposed to touch. These do not appear in any diagram because the people who created them assumed they were temporary, and then left.
The dependency that breaks your migration is the one that was too obvious to write down, made by someone who no longer works here.
You cannot plan around dependencies you do not know exist. The only defence is to discover them before cutover: trace real network traffic, watch what actually connects to what under production load, and treat every surprise as a lead rather than noise. Discovery is not a phase you can skip to save time. Skipping it just moves the discovery to the worst possible moment.
Data that is subtly wrong
This is the risk that hurts most, because it is invisible until it is expensive. Long-lived systems accumulate data that does not match its own schema: dates in the wrong format in a fraction of rows, statuses that no longer mean what they say, records left in impossible states by a bug fixed years ago. The current application copes because it has grown compensating logic around every one of these flaws. Nobody remembers writing that logic. It just works.
When you migrate the data cleanly into a new system that enforces the rules the old one never did, the compensations vanish and the flaws surface all at once. A field that was never truly required is suddenly rejected. A duplicate that the old code silently deduplicated now creates two records. The data was wrong the whole time. The old system was the bandage.
- Profile the data before you move it, not after. Find the rows that violate the rules you are about to enforce.
- Decide deliberately whether to clean each anomaly, carry the compensating logic forward, or relax the new rule. All three are valid. Discovering the choice at cutover is not.
- Reconcile after loading. Count and compare. A migration that loses or duplicates a fraction of a percent of records is a migration that has already failed, quietly.
Keeping the business running during the move
The business does not pause while you migrate. Orders keep arriving, data keeps changing, and any downtime is real money and real trust. This constraint, more than any technical detail, shapes how a migration must be sequenced. A clean, offline copy from old to new is simple to reason about and almost never available to you, because the source keeps changing while you copy.
That is why serious migrations run the old and new systems in parallel for a period, keep data flowing between them, and are built so you can turn back. The ability to reverse the cutover is not an admission of doubt. It is the thing that lets you cut over at all, because it turns an irreversible bet into a reversible experiment.
Sequencing
Order the work so that risk is paid down early and the irreversible step comes last, when you already have evidence it will hold.
- Discover first. Map the real dependencies and profile the real data before committing to any plan. The plan depends on what you find here.
- Move the low-risk, low-coupling pieces early. Prove the platform, the pipeline, and the team's process on something that cannot take the business down.
- Run in parallel. Get old and new working side by side with data synchronised, so you can compare behaviour on real traffic before you depend on it.
- Cut over the critical path last, in the smallest reversible step you can manage, with reconciliation ready and a tested way back.
Done in that order, the frightening moment at the end is small, because every genuine risk has already been surfaced and retired. Done in the wrong order, the cutover becomes the discovery phase, and you are debugging undocumented dependencies and bad data live, with the business waiting.
The platform will be fine. It is the move that needs the respect. Careful discovery, honest data work, and reversible sequencing are the whole game, and they are the heart of how we approach cloud engineering. If you are planning a migration and the cutover is what keeps you up at night, that instinct is correct, and a short consultation early is worth more than any amount of reassurance about the destination.