Cloud Migration Assessment: What to Look For

An assessment that cannot put a responsible individual against every workload has not finished its job, whatever the discovery tool reports back.

Apply that test before you read a single finding. Walk the scope list and ask, for each system, which individual accepts the risk of moving it. Where the reply comes from a team mailbox or a vendor, the engagement will end with a document that no executive has accepted, and the migration will stall at the first difficult decision.

A cloud migration assessment gives four things: what you have, what should move, what the move will cost, and what could go wrong. They arrive as an inventory, a placement decision for each workload, a costed target architecture, a sequencing plan and a risk register. The migration itself is later, separate work.

The checklist below runs in the order the checks happen, from the brief through to the weeks after the first batch crosses. Each section says what it takes in and who needs that stage. It does not teach discovery tooling, cost modelling or cutover mechanics; those live on the pages beneath this one. The go/no-go question that comes before all of it belongs to When Cloud Migration Is Worth It.

Checks in the brief, before any discovery work starts

Who needs this stage: whoever commissions the assessment, the finance lead, and the executive who will accept the risk it reveals.

• The brief identifies the executive who approves the output. An IT manager can commission the work; that individual cannot accept the risk it exposes.
• The brief defines which decision the assessment informs: placement, sequencing, cost, or all three at once.
• Exit criteria are put down in advance. Which finding would narrow the work, and which would call it off?
• Workloads are listed by business sponsor and by system, rather than by hostname or IP address.
• Deliverables are defined in nouns: risk register, target architecture, sequencing plan, cost model, keep-in-place list.
• The assessment budget is held apart from the migration budget, so an expensive finding does not become an argument about affordability.
• The delivery window is agreed, together with the effort the assessment needs from your own staff. ANS reports that its Cloud Navigator assessment is delivered in four to six weeks with minimal effort from internal teams (ANS).
• Legal, compliance and security each have a representative on the review, rather than an invitation to comment once the findings are final.
• The team that will run the migration runs the assessment, or has a right of challenge over it.
• Somebody has asked what happens if the recommendation is to leave a workload where it is. If that reply is unacceptable, the assessment is theatre.

Checks while discovery is running

Who needs this stage: the discovery lead, the application sponsors who validate tool output, and the planner who groups workloads into batches.

Microsoft's Cloud Adoption Framework treats this phase as the one that has to give full visibility into every component, dependency and requirement before anything moves (Microsoft Learn). Discovery returns an inventory; the placement decision comes after it. Atlassian's app assessment guidance works at the smallest unit, listing every on-premise app, whether an equivalent exists in Cloud, and which features differ, so the plan is built on what the move will keep (Atlassian).

• Automated discovery has run across every server, database, application and code repository in scope.
• Application sponsors have validated the tool output. Microsoft reports that discovery tools "might miss undocumented dependencies", so confirmed findings count for more than raw ones.
• Baselines exist for CPU, memory, disk reads and writes, IOPS, network throughput, peak concurrency and transaction response times.
• The baseline spans a full business cycle, including month-end or peak trading, rather than a quiet Tuesday morning.
• Configuration is logged: operating system versions, virtual machine sizes, physical server specifications, storage type and capacity, GPUs and other special hardware.
• Licence entitlements are logged, with each renewal point attached to the workload that depends on it.
• The identity inventory lists service accounts, user accounts and API keys, including anything hard-coded into an application.
• Encryption for data at rest and in transit is documented for each workload.
• Firewall rules, network security rules and access control lists are captured.
• Internal dependencies come from observed runtime connections, rather than from a diagram last updated years ago.
• External dependencies are catalogued: SaaS platforms, partner APIs, on-premises systems and data pipelines.
• Every dependency is marked read-only, write-only or bidirectional.
• Findings live in a repository a planner can query, and it is updated as the picture changes.

Tooling differs by workload type, which is why one discovery pass rarely reaches everything:

Table of tooling by workload type, from Microsoft's workload assessment guidance.

Checks at the placement decision

Who needs this stage: the architecture lead, the application sponsor who will live with the result, and the finance lead who has to fund it.

The NHS Cloud Centre of Excellence guidance is blunt about the two forces that push applications in the wrong direction: strong familiarity with the existing environment, and an overenthusiastic appetite for cloud services (NHS cloud migration guidance). Placement is decided against attributes logged for each workload. That same guidance asks for a risk score per application, on the reasoning that teams starting out should begin with low-risk workloads so a mistake does not jeopardise the wider cloud initiative. Value runs alongside technical fit, and the two pull apart often enough to be worth scoring on separate lines: the applications worth the most are frequently the ones that need the most work before they will run in a cloud tenancy.

LeanIX lays out seven domains a placement decision has to settle for each application (LeanIX).

• Each workload gets one of five treatments: rehost, revise, rearchitect, rebuild or replace. The NHS guidance links rehost and revise to IaaS, rearchitect and rebuild to PaaS, and replace to SaaS, while warning that the link is a tendency rather than a rule.
• The cloud tier is chosen with the treatment, and the reason for the tier is put down where an auditor can read it.
• Any workload that cannot move goes onto a keep-in-place list with the rule that blocks it: latency, a regulatory constraint, or a licence that does not transfer.
• The finding is a decision for each workload. A list of everything you run, with no treatment against it, leaves the migration team to guess.

Checks while the move is under way

Who needs this stage: the migration lead, the change manager, and the individual who will approve the crossing for each batch.

• Every batch has a tested rollback, exercised against a non-production copy of the workload, rather than one that exists only on paper.
• The crossing has a maximum window agreed with the business, and a point at which the team withdraws and reverts.
• Identity and access controls are live on the target platform before production traffic arrives.
• Monitoring and alerting are switched on before the crossing, with thresholds taken from the discovery baselines.
• The cost meter is running before the first production resource is created, not after the first invoice arrives.
• Dependent systems cross together, in the order the dependency map from discovery gives.
• Someone outside the migration team can call off the crossing, and the plan lists who that individual is.
• The support rota covers the weekend after the crossing, not just the working week.

Checks from the end of the move to day ninety

Who needs this stage: the operations lead, the finance lead, and the sponsor who accepted the risk.

• Performance is set against the pre-migration baselines, and any shortfall has an action against it.
• Cost per workload is checked against the model that came with the assessment.
• The keep-in-place list is reviewed, and every workload still on it has a review point.
• Licences kept alive through the overlap have been ended.
• Decommissioning of the source environment has begun, with data destruction evidenced.
• Risk register entries closed during the move have been closed on evidence, not on optimism.
• The next batch's scope has been updated to reflect what this one taught.

Where the assessment ends and the plan begins

Five artefacts make the handover: an inventory with a sponsor against each workload, a placement decision for every item on it, a costed target architecture, a sequencing plan, and a risk register with an action against each entry. Where one of the five is missing, the migration planning stage will invent it, late and badly.

The assessment does not decide whether the move is worth making. That case belongs to When Cloud Migration Is Worth It, and it comes first. It does not choose the cloud tier in isolation from the placement decision, because tier and treatment are settled together. And it does not end at what you have. An inventory with no treatment against it hands the hard part to whoever runs the migration, with less time and less information.

Sources

• Cloud migration guidance
• Assess your workloads for cloud migration
• Cloud migration app assessment
• Cloud Migration Assessment
• Cloud Migration Assessment: Process & Tools