Migration sales cycles have a way of feeling reassuringly thorough. The proposal is long, the slides are polished, the references say nice things, and the number at the bottom looks defensible. Yet the failures that hurt most rarely come from a partner who set out to do a bad job. They come from assumptions nobody tested before signature: that dependencies were understood, that cutover was a single quiet night, that someone would still be answering the phone the week after go-live. For IT leaders planning a move of workloads to AWS, the evaluation period before the contract is the cheapest risk control available. What follows is a practical set of tests you can apply to any candidate — grounded in how a disciplined AWS migration is actually delivered — so that you judge capability rather than presentation.
The First Test: Do They Plan Before They Touch a Server?
A well-run Amazon cloud migration begins with discovery, not tooling. That distinction is worth pressing on hard during evaluation, because a partner who arrives with a tool list and a timeline before they have seen your environment is selling a template, not an engagement. The first phase of serious work — typically the opening couple of weeks — should be spent reviewing the current estate, identifying candidate workloads, and mapping both infrastructure and application dependencies. If a candidate cannot describe what those dependency maps and workload inventories will look like as deliverables, that is a warning sign. Ask to see the artefacts, not the methodology slide.
From there, architecture design and readiness assessment should follow, with test migrations used to surface compatibility problems while they are still cheap to fix. Ask specifically how they determine whether a workload is ready for AWS, and how they build a landing zone before anything moves. A hardened landing zone is where security gaps get prevented rather than discovered later, so expect a candidate to talk credibly about account structure, identity and access through IAM, guardrails, and security services such as GuardDuty, Security Hub, CloudTrail, and WAF. If security validation is treated as a checkbox at the end instead of a design input, keep looking.
Tooling matters, but as a secondary signal. Competent teams work with AWS Application Migration Service, AWS DMS, and AWS SCT, and design against core services such as EC2, S3, RDS, Aurora, ELB, Route 53, and IAM, with containers on EKS, ECS, or Fargate where the target architecture calls for them. What you are listening for is whether the tool choice follows a decision about the workload, or precedes it. Servers, databases, applications, VMware workloads, and entire data centers all land on a migration list, and lift-and-shift suits some while re-platforming suits others. A partner who can explain which path each workload will take and why — including database migrations and hybrid scenarios — has done the thinking. A partner who quotes a single uniform approach has not. Be equally wary of firm timelines offered before discovery; the honest answer to “how long will this take?” always starts with what is actually in your racks.
The Second Test: Cutover Discipline, Rollback, and What Happens After Go-Live
Cutover is where migration projects become visible to the rest of the business, and it is the part of the proposal most often described in generalities. Push for specifics. How is cutover handled? Which activities are planned in advance, who owns each one, and — critically — what does rollback readiness look like if something behaves differently in production than it did in testing? A failed cutover without a rollback plan does not stay a technical problem; it becomes a business-wide outage. Insist on seeing cutover runbooks as a deliverable, and ask how work is divided into waves, because multiple waves each carry their own risk profile and need their own controls.
Testing deserves the same scrutiny. Pre- and post-migration testing should confirm that performance held up after the move, and data protection should rest on backups plus validation rather than optimism. A credible aws migration company will be able to explain how scope governance and PMO control prevent overruns during execution, and how rightsizing and cost review stop the bill from climbing once the environment is live. These are not nice-to-haves; they are the mechanisms that separate a controlled project from an expensive surprise.
Then ask about the period everyone forgets: hypercare. Performance problems and rising bills tend to appear after a project is declared finished, which is exactly when attention drifts elsewhere. Post-migration support usually runs 30 to 90 days, and during that window you should expect monitoring, performance tuning, and a cost review that checks whether the new environment is paying its way. Ask directly whether the team that performed the migration stays through go-live and stabilization, or whether the engagement ends at the handover meeting. Also confirm how handover actually works: documentation, architecture diagrams, runbooks, and knowledge transition sessions that let your own engineers operate the environment, followed by cleanup of external access when the engagement closes. Hypercare and handover are the two areas where the cheapest engagement model quietly becomes the most expensive one.
The Third Test: Engagement Model, Timelines, and the Handover You Actually Get
Migration partners structure work in very different ways, and the right shape depends on what your team can absorb. Some organizations want a scoped assessment and discovery project only — workshops, dependency mapping, and TCO modelling — then decide how much hands-on help to buy. Others commission a one-time migration project and add monthly or annual managed post-migration support alongside it. Larger programs may need a pod of migration architects, cloud and infrastructure engineers, and database specialists working beside your staff, or an annual transformation engagement with a steering review each quarter. During evaluation, ask which of these models is genuinely on offer and which one the partner is trying to steer you toward. A vendor that only sells one model will describe your needs in terms of it.
Timelines are a useful cross-check. As a rough frame, an assessment runs one to three weeks, small projects two to six weeks, and complex multi-wave programs two to six months, with post-migration support following for 30 to 90 days. Real projects shift with scope, so treat any candidate who presents these as fixed commitments with suspicion — and treat a partner who explains what would cause a timeline to move, and how you would be told, as more trustworthy. Maturity of delivery shows in a consistent four-stage shape: discovery and dependency mapping, architecture and readiness, execution and cutover, then hypercare and optimization. The first two stages typically occupy roughly the first thirty days, leaving the migration window itself for stage three. Ask each candidate to map their proposal onto those stages and to show where your team’s responsibilities sit.
Finally, separate direct costs — assessment, delivery, tooling — from indirect ones, where the payoff shows up as lower operating costs and better scalability. Ask every candidate which delivery model they are proposing, whether consulting is available for the assessment and strategy stage alone if that is all you need, and who handles stabilization and long-term management once cutover ends. Different organizations arrive here for different reasons: a SaaS product team wants room to scale, a fintech platform wants tighter security, an online retailer wants peak-season traffic to stop feeling like a gamble. The right partner is the one whose answers describe your environment, your risks, and your team’s ability to run what they leave behind — in writing, before you sign.
A Pampas-raised agronomist turned Copenhagen climate-tech analyst, Mat blogs on vertical farming, Nordic jazz drumming, and mindfulness hacks for remote teams. He restores vintage accordions, bikes everywhere—rain or shine—and rates espresso shots on a 100-point spreadsheet.