Every enterprise cloud migration that goes badly looks the same in hindsight. The workloads moved. The dashboards turned green. Six months later the bill is 40% over forecast, three applications are slower than they were on-premises, and nobody can explain why.
The failure almost never happens during the migration. It happens in the four weeks before it, when the assessment is treated as a formality instead of the most important deliverable in the programme.
Here is the readiness checklist we run before we move anything — and what it usually turns up.
1. Build a real dependency map, not an application inventory
Almost every organisation has an application inventory. Almost none have a dependency map.
An inventory tells you that you run 140 applications. A dependency map tells you that application #37 — a reporting tool nobody has thought about in three years — holds an open connection to the core ERP database, and that moving the ERP without moving it will break month-end close.
The distinction matters because migration waves are built from dependency clusters, not from application lists. Group by dependency and you move coherent units that keep working. Group by business unit or by "easy ones first" and you spend the programme firefighting broken integrations.
The single most common cause of migration rollback we see is an undocumented dependency discovered at cutover — not a technical failure of the cloud platform.
Run discovery tooling for a minimum of 30 days. Anything shorter misses monthly batch jobs, quarter-end processes, and the reporting run that only fires on the last Friday of the month.
2. Establish a defensible cost baseline
"Cloud will be cheaper" is a claim, not a plan. To test it you need the real current cost of running each workload, and most organisations do not have this number.
A defensible baseline includes:
- Hardware amortisation, not just the original purchase price
- Data centre space, power, and cooling apportioned per workload
- Licensing — especially the per-core licences that get dramatically more expensive in cloud if you do not plan for it
- The share of IT staff time spent on infrastructure maintenance
- Backup, DR, and the storage tiers behind them
Once you have this, model the target state honestly. Include egress charges, inter-region traffic, managed service premiums, and support plan costs. A migration that is projected to save 8% is not a cost programme — it is an agility programme, and it should be justified on those grounds instead.
3. Decide the disposition of every workload before you start
The six Rs are well known. Applying them rigorously is not.
| Disposition | Use when | Typical effort |
|---|---|---|
| Rehost | Time-boxed exit from a data centre lease | Low |
| Replatform | Managed database or runtime gives an immediate win | Medium |
| Refactor | The application is strategic and the current architecture blocks it | High |
| Repurchase | A mature SaaS product covers the same need | Medium |
| Retire | Usage data shows it is genuinely unused | Low |
| Retain | Latency, compliance, or licensing makes cloud the wrong home | None |
The disposition decision has to be made per workload, with a named owner, before the wave plan is finalised. Deciding it during migration is how a rehost quietly turns into a nine-month refactor.
One finding that surprises clients every time: on a typical estate, 10–15% of applications should simply be retired. Nobody uses them. Migrating them costs real money and buys nothing.
4. Close the identity and security gaps first
Cloud migration is an identity project wearing an infrastructure costume. Everything in our cloud and modern workplace practice starts here for exactly that reason.
Before the first workload moves, you need answers to:
- Where is the authoritative identity source, and is it clean? Orphaned accounts and stale group memberships become cloud entitlements the moment you sync them.
- Is conditional access enforced, and does it survive the migration?
- What is the privileged access model in the target environment? Standing admin rights that were tolerable behind a firewall are a serious exposure in a cloud control plane.
- How is data classified, and which classifications have residency constraints? For clients operating across India and the GCC this is frequently the constraint that reshapes the entire target architecture.
- Which logs go where, who reviews them, and what is the escalation path?
Security controls retrofitted after migration cost several times what they cost designed in. This is why our cybersecurity and cloud practices run as one engagement rather than two. More importantly, the retrofit window is exactly when the environment is least monitored and most exposed.
5. Define what "done" means, numerically
A migration without exit criteria never finishes. It just gradually stops being talked about.
Define, per wave, the numbers that constitute success:
- Application response time at the 95th percentile, compared to the pre-migration baseline
- Monthly run cost against the modelled forecast, with an accepted tolerance band
- Backup and restore verified by an actual test restore, not by a green tick in a console
- Decommissioning completed — the on-premises footprint switched off, not just idle
- Runbooks updated and the operations team signed off on them
That fourth point deserves emphasis. Running both environments in parallel "just in case" is the single largest source of cloud cost overrun we encounter. If the old environment is still powered on ninety days after cutover, the migration is not finished and the savings case is already broken.
What this looks like in practice
For a mid-sized enterprise estate — 100 to 200 applications — this assessment takes four to six weeks and typically changes the migration plan substantially. The most common outcomes:
- The wave sequence is reordered around dependency clusters
- Somewhere between 10% and 20% of applications are removed from scope entirely
- At least one workload is reclassified as retain on residency or latency grounds
- The cost case shifts from "cheaper" to "more flexible, at comparable cost" — which is a defensible position, and a much more durable one once the invoices start arriving
Four weeks of assessment against a programme that will run for twelve to eighteen months is not overhead. It is the cheapest risk reduction available to you.
ATMOREX runs cloud readiness assessments for organisations across India, Qatar, and Bahrain, covering Azure, AWS, and hybrid estates — see the full range of services we deliver, or read more about how we work. If a migration is on your roadmap for this year, a conversation now is worth more than a rescue engagement later.