Migration is the easy part
Every page about cloud migration services shows you a phase diagram. Assess, plan, migrate, optimise, with an arrow between each. They are all broadly the same diagram because the method is genuinely well understood by now, and a competent partner will get your workloads across.
The diagram stops at the moment the real problem starts. On the Monday after cutover you own an estate that is larger, more complex and less familiar than the one you had — and you own it with the team you already have. If that team was already stretched, migration has not solved your problem. It has enlarged it.
That is the part this page is about.
Built for platform teams running under a headcount cap
If you run cloud platform for a global capability centre, the shape of the constraint is familiar. The parent organisation has decided to move more workloads into your region. Headcount is approved in numbers that assume the estate is static. Senior cloud engineers are the hardest role in the market to hold onto, and your attrition on exactly those roles is the risk nobody wants to put in the migration plan.
So the question in front of you is not whether the migration can be executed. It is whether what you are left with is operable by the people you can actually keep.
That changes what a good migration looks like. It means preferring the path that leaves less operational burden even when it costs more up front. It means guardrails and runbooks being migration deliverables rather than a later project. And it means that every operator action afterwards is logged, reviewable and approvable — because that is what lets a mid-level engineer safely do work that would otherwise sit in a senior queue.
The 6 Rs, scored by what they leave you to run
Every migration page lists the six Rs. None of them connect an R to the operational load it leaves behind, which for a capped team is the only column that matters.
| Path | Migration effort | Day-2 operational load | Who can run it afterwards |
|---|---|---|---|
| Retire | Lowest | None | Nobody — and that is the point. Always do this pass first. |
| Retain | None | Unchanged, but now split across two estates | Existing team, plus the cost of context-switching |
| Rehost (lift and shift) | Low | Highest. You moved the problem, including the patching, the snowflake config and the undocumented cron job | Needs the same seniority it always did |
| Replatform | Medium | Meaningfully lower — managed services absorb patching, backup and failover | Mid-level, with runbooks |
| Repurchase (move to SaaS) | Medium | Lowest of the active options | Vendor runs it; you run the integration |
| Refactor | Highest | Low once stable, high during the first two quarters | Needs senior capacity you may not have |
Read that third column and the usual advice inverts. Rehost is the cheapest migration and the most expensive thing to own. For a team with capped headcount, replatforming the workloads that carry the most operational toil is usually the better trade, even though it extends the project. The question to ask of each workload is not “what is the fastest way across” but “who is on call for this in March”.
How it works
- Assess. Inventory what exists, what it costs, who owns it and what it depends on. Score each workload on the table above — migration effort against day-2 load — rather than effort alone. The retire pass happens here and usually removes more than anyone expects.
- Migrate. Move in waves, lowest-dependency first, with the account structure, tagging standard and guardrails in place before the first workload lands rather than retrofitted after the last one.
- Hand over. Runbooks, infrastructure as code, and an operating model that names who does what. The engagement ends when your team can run it, not when the last workload moves.
Governance and audit from day one
Compliance badges tell you a vendor passed an audit. They do not tell you who ran what in your environment last Tuesday, or who approved it. For a GCC answering to a parent organisation’s risk function, that second thing is the one that gets asked about.
Every operation follows the same sequence — Ask → Plan → Approve → Execute → Audit. The plan is itemised and visible before anything runs. Execution waits for a human approval; that gate is not a configurable setting. Every action is recorded with its approver and reviewable months later by someone who was not there.
The Runtime deploys into your own AWS account and operates through IAM roles you connect and can revoke. No AWS access keys are handed over at any point. The control plane handles portal login, workspace entitlement, activation and connectivity metadata, and nothing else.
What you own on day 90
Stated as a commitment rather than a bullet, because dependency on a migration partner is the thing a capped team is specifically trying to avoid.
- Infrastructure as code for everything that was migrated, in your repository, that your team can read and change.
- Runbooks for the operations that recur, written to be executed by someone who was not on the migration.
- An operating model document naming who holds what, how escalation works, and what remains outstanding.
- A full audit trail of every operator action taken in your environment during the engagement.
If a migration partner cannot tell you what you will own at the end of it, that is the answer to the question.
Frequently asked questions about cloud migration services
What are cloud migration services?
Cloud migration services cover assessing an existing estate, choosing a migration path for each workload, moving applications and data, and establishing operations on the other side. The assessment and the handover are the parts that determine whether the migration was worth doing; the move itself is the best-understood step.
What happens after the migration is complete?
That is the question worth asking a prospective partner, because most engagements end at cutover. You should expect infrastructure as code in your own repository, runbooks written for someone who was not on the project, a documented operating model naming who holds what, and an audit trail of every action taken in your environment.
What is the difference between rehosting and replatforming?
Rehosting moves a workload as it is — fastest to migrate, and it carries every operational quirk with it, including the patching, the hand-tuned configuration and the undocumented scheduled jobs. Replatforming changes components to managed equivalents during the move, which costs more up front and leaves materially less to operate afterwards.
How long does a cloud migration take?
It depends almost entirely on dependency complexity rather than workload count. A single well-understood application can move in weeks. A connected estate with shared databases and undocumented integrations takes quarters, and the assessment phase is where that becomes visible. Any estimate given before an assessment is a guess.
Why do cloud migrations fail?
Rarely at the technical step. The common failures are migrating workloads that should have been retired, choosing rehost everywhere because it is fastest and inheriting all the operational debt, and ending the engagement at cutover with no runbooks and no operating model — which leaves a larger estate owned by the same team with the same capacity.
Does the platform need our AWS access keys?
No. The Runtime deploys into your own AWS account and operates there through IAM roles you connect and can revoke. No access keys change hands. Every change is planned, approved by a person, executed and logged.
Where to go from here
Three places to go next:
See what your estate looks like before you commit to a path
Connect two AWS accounts on the free trial and run an assessment. The plan is itemised before anything executes, and nothing runs without your approval.
No credit card required. Your trial clock starts when the Runtime connects.