What an AWS migration assessment covers

Before anything moves to AWS, someone should write down what you have, what each system is for and what should happen to it. That is an AWS migration assessment. This piece covers what a good one includes, which parts AWS’s own tools now do for you, what you should get in writing, and what tends to go wrong when organisations skip it.

What is an AWS migration assessment?

An AWS migration assessment is a short, fixed-scope piece of work done before a migration that inventories your applications and data, checks how ready your organisation is to run on AWS, and decides what should happen to each system. You may also see it called a cloud readiness assessment or a migration readiness assessment.

It has two halves. The readiness half looks at people, process, security and operations; AWS frames it around the six perspectives of its Cloud Adoption Framework in what it calls a Migration Readiness Assessment. The portfolio half looks at every application and the data it holds.

It is also the first of three phases in AWS’s Migration Acceleration Program: Assess, Mobilize, then Migrate and Modernize.

What it covers

A good assessment produces six things.

• An inventory with owners. Every application, server and data store, and the person in the business who is accountable for it.

• A dependency map. Which systems talk to which, so you know what breaks if one moves first.

• A decision for every application. AWS describes seven migration strategies, often called the 7 Rs:

  • Retire: switch it off.

  • Retain: leave it where it is, for now.

  • Rehost: move it as is (“lift and shift”).

  • Relocate: move a whole virtualised platform without changing it.

  • Repurchase: replace it with a SaaS product.

  • Replatform: move it with small changes, such as a managed database.

  • Refactor: redesign it to use cloud services properly.

• A target architecture on AWS, including which Australian region it runs in: Sydney (ap-southeast-2), Melbourne (ap-southeast-4) or both.

• Your obligations in writing. Privacy Act duties, APRA’s CPS 230 if you are regulated, IRAP if you work with government, and any contract terms about where data lives.

• A phased plan and an indicative cost range, covering both the move and what it costs to run afterwards.

The assessment is also where you decide what not to migrate. In most estates, some systems should be switched off rather than moved, and finding them is one of the quickest wins the work produces.

The part the tools now do for you

AWS’s own tools have taken most of the effort out of the infrastructure half. AWS Transform takes a server inventory, such as a VMware export or a configuration database, and generates a total cost of ownership business case “in minutes”, with right-sizing, licensing analysis and side-by-side scenarios. AWS’s Migration Evaluator does similar work and can collect the inventory for you.

That is good news. A few years ago, the server spreadsheet alone took weeks.

What the tools can’t tell you is whether an application is still worth having, what the people who use it struggle with, which data has to stay onshore, or what order is safe to move things in. They price the estate you have. They don’t question it.

The cost model is now the easy part. The decisions are the work. That is where an assessment earns its fee, and it is the part to check when you compare proposals.

What skipping it costs

Most of the expensive problems in a migration are decisions made too late. These are the common ones.

Moving things you should have retired

Without an inventory and an owner for each system, everything gets migrated. AWS’s own guidance suggests looking for “zombie” and idle applications, with very low usage, and retiring them instead. Every system you move without asking whether it is still needed is a system you pay to move and keep paying to run.

Rebuilding in the middle of the move

AWS calls refactoring “the most complex and costly” of the seven strategies, and for large migrations recommends moving first and modernising afterwards. Without a plan, teams discover halfway through that an application won’t run as is, and start redesigning it under deadline.

Dependencies found at cutover

The reporting job that quietly feeds payroll. The file share another team still writes to every night. A dependency map finds these on paper, when they are a line item rather than an outage.

Compliance found late

Data that must stay in Australia, a regulator that expects notice of material changes to critical operations, or a contract clause about where records are held. Found during the assessment, these shape the architecture. Found after it, they unpick it.

Funding left on the table

AWS’s Migration Acceleration Program can offset part of the cost of a qualifying migration. Eligibility is AWS’s call, and the evidence it looks at comes from the assessment. Without one, the conversation with AWS has nothing to start from.

How long it takes and what you get in writing

For a mid-sized organisation, an assessment usually takes four to six weeks. Where it lands in that range depends mostly on how many applications are in scope and how many teams use them. We run ours at a fixed price, agreed before we start, so the assessment itself never becomes open-ended.

Whatever the timeframe, you should finish with documents you can act on without the partner who wrote them:

• The inventory and dependency map.

• A decision and a short rationale for each application.

• The target architecture and region.

• The compliance obligations and how the design meets them.

• A phased plan with an indicative cost range for moving and for running.

If the output is a slide deck and a quote for the migration, it was a sales step, not an assessment.

Questions to ask before you commission one

• Who will talk to the people who use these systems, not just the people who run them?

• Is “retire” on the table, and will you tell us if a migration doesn’t make sense?

• Which AWS region will each workload run in, and what has to stay onshore?

• Will we get a cost range for running on AWS, not just for moving?

• Do we own the output, and can we take it to another partner?

• How will the findings support a Migration Acceleration Program application, if we qualify?

How Honest Fox runs an assessment

We are a digital product company with AWS-certified engineers, so an assessment with us has two sides running at once. Our researchers and designers talk to the people who use your systems, while our engineers map the estate and its dependencies. That is how we find the applications worth changing, not just moving, and the ones worth switching off.

We are an AWS Partner at Select Tier Services. The assessment follows the same shape as our delivery: decisions are written down and agreed before anything is built, as in spec-driven development.

Thinking about moving a platform to AWS? Ask us what an assessment would cover for you.

Frequently asked questions

Is a cloud readiness assessment the same as a migration assessment?

Mostly. A cloud readiness assessment usually means the organisational half: skills, processes, security and operations. A migration assessment adds the portfolio half: every application, its dependencies and a decision about what happens to it. A useful assessment covers both, because a ready organisation with the wrong migration plan still has a problem.

Does AWS pay for migration assessments?

Sometimes. AWS’s Migration Acceleration Program can offset part of the cost of a qualifying migration, and assessment results are part of how AWS judges whether you qualify. Eligibility depends on the size and type of workload and is AWS’s decision, so treat funding as a possibility to check rather than a given.

Can we do the assessment ourselves with AWS’s tools?

You can do the infrastructure half yourself. AWS Transform and Migration Evaluator will build a cost business case from a server inventory. What they won’t do is decide which applications to retire, change or keep onshore, or talk to the people who use them. Many organisations run the tools themselves and bring in help for those decisions.

Do we have to migrate with the partner who did the assessment?

No. You should own the output and be able to take it to any partner, or run the migration yourselves. If a proposal ties the assessment to a migration contract, ask why.