Cloud Migration Readiness Assessment: What to Do Before You Pick a Partner

A cloud migration readiness assessment is a structured review of your current infrastructure, applications, data, compliance posture, and team capacity, producing a migration roadmap that sequences which workloads move first, which need re-architecture before moving, and which should not move at all. Running this assessment before you pick a migration partner protects you from three common failure modes: scoping the engagement against bad assumptions, picking the wrong partner for the actual complexity, and discovering late that the migration your leadership approved is not the migration your environment needs.

TL;DR

• The readiness assessment happens before vendor selection. Doing it in the wrong order is how you end up with a partner whose proposal was built for an environment that does not match yours.
• Assessment covers five dimensions: infrastructure, applications, data, compliance, and team.
• Output is a roadmap with specific workloads, specific sequences, specific cost and timeline estimates.
• Budget four to six weeks and roughly five to ten percent of the eventual migration budget for the assessment itself.
• The assessment pays for itself by preventing the ten to thirty percent of migration budget that is typically wasted on re-work when it is skipped.

Why this comes before vendor selection

The sequencing mistake that shows up most often in mid-market cloud programs: leadership decides to move to cloud, issues an RFP to three migration firms, receives three proposals, picks one, and starts the engagement. The proposals are based on what each firm understood from the RFP and the two-hour sales call. The migration starts. Three weeks in, the winning firm discovers an undocumented dependency that doubles the scope of a workload. A month in, someone realizes the compliance framework the sales team did not ask about requires a landing zone architecture nobody bid.

The migration continues, but now every scope question is a change order. The budget overrun starts at ten percent and climbs from there.

The alternative sequencing: run the readiness assessment first. The output is a detailed picture of your actual environment — what is here, what it does, what it depends on, and what constraints are non-negotiable. Use that picture to write a real RFP, get proposals that are grounded in real scope, and select a partner whose expertise matches the actual complexity.

You can run the assessment with a firm that will also bid on the migration (we do this with some clients), with a separate advisor, or internally if you have the capacity. Who runs it matters less than whether it happens.

The five dimensions

1. Infrastructure

What exists today. Servers (physical and virtual), networking equipment, storage systems, databases, appliances, and the dependencies between them. This seems like the easy part and is usually the messiest.

Specific questions:

• Where does every production workload run? Not “the data center” — the specific rack and server.
• Which workloads share hardware or have noisy-neighbor dependencies?
• What is the current capacity utilization? What is the growth trajectory?
• What is on an on-prem hypervisor versus bare metal versus co-located versus already in some cloud?
• What is the network topology and where are the firewall enforcement points?
• Which systems are in support and which are end-of-life (hardware or software)?

Expected output: a workload inventory spreadsheet with at least the above attributes per workload, reviewed by the people who actually operate the environment.

2. Applications

What the workloads do. An infrastructure inventory tells you what exists; the application inventory tells you what each workload is for, who depends on it, and what breaks if it is down.

Specific questions:

• Which business processes depend on this application?
• Who are the owners (business-side and IT-side)?
• What is the current architecture (monolith, microservices, SaaS-integrated, legacy client-server)?
• What are the runtime dependencies (other internal applications, external APIs, specific middleware)?
• What are the performance and availability SLAs, stated or implied?
• How often does it change? (A never-updated application is a different migration problem than one that deploys weekly.)
• Is there an active vendor relationship, and does moving it affect license agreements?

The hardest part of the application inventory is usually not assembling it — it is pushing past first-order answers. “This app is used by sales” is not enough; “this app is the system of record for pipeline data and feeds three downstream analytics processes” is useful.

3. Data

Where the data lives, how it flows, and what regulations apply to it.

Specific questions:

• What data is in each application database, and what is its sensitivity classification?
• What are the data flows between systems? What integrations exist, and what patterns do they use (API, file transfer, direct database, ETL)?
• What is the data volume per workload? The growth rate?
• What are the backup and recovery requirements?
• What regulatory or contractual constraints apply to data location (GDPR, CCPA, PIPEDA, HIPAA, contractual data residency)?
• Is there data that must remain on-prem for regulatory or contractual reasons, and does that affect migration architecture?

Data is the dimension most likely to surprise you during migration. A workload that looks straightforward to move often has data flows that are underdocumented, and those flows are where the migration actually gets hard.

4. Compliance

What regulatory, industry, or contractual frameworks apply, and what the cloud migration implications are.

Specific questions:

• Which frameworks apply? (Industry regulations, contractual obligations in customer agreements, certifications your company holds.)
• Which cloud providers and regions are acceptable under each framework?
• What controls are required, and how do they translate to cloud-native services?
• What evidence must be retained, in what form?
• Do any frameworks require data residency or data sovereignty guarantees?
• Is there a precedent for audits of cloud environments in your framework? What did the auditors expect to see?

Compliance constraints often narrow the migration options before cost optimization has a chance to weigh in. Better to know that early than to design a cost-optimal architecture and then discover your compliance team will not approve it.

5. Team

What your operations team can do, and what they will need to learn or hire for.

Specific questions:

• Who currently operates the environment? What are their specific skills?
• Who has cloud experience, and on which platforms?
• What is the gap between current skills and the skills needed to operate the target environment?
• What training, hiring, or partnership is realistic in the migration timeline?
• Who will own the post-migration environment? Is that role defined?

This is the dimension most readiness assessments skip or skim. It is usually the most common cause of post-migration problems. A technically successful migration to an environment nobody on your team can operate is a worse outcome than a slower migration that matches your team.

How to run the assessment

Week one. Kickoff, scope confirmation, stakeholder identification, start of documentation review. Identify the inventory templates you will populate and assign owners.

Week two. Infrastructure and application inventories populated by your team with guidance. Initial stakeholder interviews. Evidence collection from monitoring, CMDB, documentation systems.

Week three. Data flow mapping. Compliance review. Team skills assessment. Start of workload analysis.

Week four. Workload-level analysis: for each workload, assess migration complexity (straight lift-and-shift, replatform, refactor, leave alone), prerequisite work, and rough effort. Draft sequencing.

Weeks five and six (as needed). Roadmap finalization. Cost and timeline modeling. Written deliverable. Executive readout and roadmap review session.

For mid-market environments with a hundred or fewer workloads, four weeks is often enough. For larger environments or high complexity, plan for six.

What the deliverable should contain

A good readiness assessment deliverable has the following sections at minimum:

Executive summary. Three to five pages. Strategic recommendation (move, stay, hybrid), headline timeline, headline budget range, key risks.

Current state summary. What exists, organized by the five dimensions above.

Target state recommendation. Which cloud provider(s), what architectural pattern, what the landing zone looks like.

Workload disposition matrix. Every workload with its recommended migration approach, rough effort, prerequisites, and sequencing position.

Sequencing roadmap. Phased plan, typically in waves, with dependencies and decision points.

Cost modeling. Expected cloud run-rate cost, expected migration execution cost, expected transitional cost (running both environments in parallel), ROI timeline.

Risk register. Specific risks to the migration with mitigations.

Vendor selection guidance. What to look for in a migration partner given your specific environment. What skills are mission-critical versus nice-to-have.

What you do with the output

Use it to write the RFP. The workload disposition matrix and sequencing roadmap tell prospective partners exactly what the work looks like. Proposals come back grounded rather than generic.

Use it to validate partner expertise. When a prospective partner’s proposal diverges from your assessment (on sequencing, effort estimates, or approach), you have a substantive basis for the conversation. Usually either they see something you missed (valuable) or they are proposing a generic approach that does not fit (good to catch before signing).

Use it to set internal expectations. The executive summary is the document you share with leadership to anchor timeline and budget conversations. Post-migration, it becomes the yardstick against which the actual outcome is measured.

Use it to sequence internal work. Team skills gaps identified in the assessment feed into hiring and training plans that run in parallel with the migration rather than after it.

When to skip the assessment

Rare, but occasionally defensible:

• You have fewer than five production workloads, they are all straightforward web applications, and your team has deep cloud experience already. A light-weight planning exercise is enough.
• You are moving from one cloud provider to another where the source environment is already well-documented and the migration is pattern-based.
• You have run a similar migration within the last twelve months and the organizational context has not materially changed.

In every other case, the assessment pays for itself.

How we run readiness assessments

Our cloud readiness engagements run four to six weeks. Output is the workload disposition matrix, sequencing roadmap, cost model, and vendor selection guidance described above. We do not tie the assessment to an eventual migration commitment — many clients use our assessment to run their own RFP process, and we are comfortable with that outcome. If we are a fit for the eventual migration, we will tell you at the end of the assessment; if we are not, we will tell you that too.

See the cloud practice page for the full scope of cloud engagements we run. For context on how we approach engagement scoping in general, the systems integration practice page covers our broader consulting methodology.

Frequently asked questions

Can we do this ourselves?

Yes, with enough internal capacity and a senior engineer who has done a cloud migration before. The structural challenge is that most mid-market IT teams do not have the spare capacity to pause day-to-day work for four to six weeks of focused assessment, and the senior engineer who would run it is often the person most needed for current operations. If you have the capacity, run it internally. If not, bring in help.

Does the assessment specify which cloud provider to use?

Yes — the target state recommendation includes the cloud provider choice, with the reasoning. The choice is driven by existing vendor relationships, compliance constraints, team skills, workload characteristics, and cost modeling. If the assessment does not make a recommendation, it is not doing its job.

How is this different from what the cloud provider’s own advisory team offers?

Cloud provider advisory teams (AWS ProServe, Azure Cloud Adoption Framework advisors, Google Cloud migration advisors) offer excellent technical expertise and are usually available at no cost or low cost. Their strategic recommendation, however, is nearly always to move to their platform. An independent assessment considers your specific situation without platform bias. Use provider advisory teams for deep platform-specific technical questions; use an independent assessment for the strategic recommendation.

What about multicloud?

Multicloud is a legitimate target state for some workloads and an expensive mistake for others. The readiness assessment should make a specific recommendation: single cloud, hybrid (some workloads stay on-prem), or multicloud (workloads distributed across cloud providers). A blanket “we will go multicloud” without a workload-level rationale usually produces operational complexity that outweighs the benefits.

How much does an assessment cost?

Typical mid-market readiness assessment runs a small-to-moderate five-figure engagement. Scope drives the cost — environment complexity, workload count, compliance scope. The rule of thumb is five to ten percent of the eventual migration budget, which is substantially less than the budget that typically gets wasted on re-work when the assessment is skipped.

Can we run this as a short engagement — one or two weeks?

You can, and some firms offer it. The output will be correspondingly shallow. A one-week readiness assessment is usually not much more than a workload count and a gut-feel roadmap. That is sometimes enough to start a conversation, but it is not sufficient input for an RFP.

What if we already have a migration partner selected and we are midway through?

If you are mid-migration and things are not going well, what you need is a diagnostic, not a readiness assessment. The diagnostic looks at what has been built, what is working, what assumptions the current vendor was operating on, and what the path forward looks like. We handle those as rescue engagements — see our cloud practice page for context.

Scoping a cloud migration? Book a discovery call to talk through the readiness assessment for your specific environment.