Migrate to AWS: the six phases, who does what, and when AWS helps pay.

IShould you migrate to AWS, and is now the right time?

Migration is expensive in attention even when AWS helps with the cost. Before the how, ask whether the move clears the bar for your situation and whether the timing is right.

The strongest reasons are concrete. A renewal cliff: a Heroku, VMware or colocation contract that would lock you in for another term. An inverted cost curve: PaaS dynos and add-ons that cost more than the equivalent ECS Fargate and RDS setup once you pass a few hundred dollars a month. A capability ceiling: you need managed Kubernetes, multi-region failover, a data lake or Bedrock. A compliance trigger: SOC 2, HIPAA or PCI is easier to meet when you control the network, the keys and the logs (VPC, KMS, CloudTrail).

The weaker reasons are "AWS is what real companies use" and "our investors expect it." They are real pressures, but on their own they do not justify a quarter of engineering distraction. If your app is small, your bill is a few hundred dollars a month and you have no compliance or capability gap, waiting is often the right call. The move is easier to justify once the workload is big enough to qualify for MAP and the savings pay back the disruption.

Timing matters as much as the decision. Good windows: before a renewal, before a funding round closes, and before a growth spike forces you to scale the old platform first. Bad windows: mid-incident or mid-launch. Never cut over in the month you ship the thing your company is counting on.

One more reason has become decisive in 2026: AI on AWS. If your roadmap includes generative AI features, being on AWS puts Bedrock one IAM role away instead of one more vendor and one more data-egress story. A partner can also check POC funding for the first test.

IIWhy AWS, and how partner-filed funding changes the math

Plenty of clouds can run your containers. The case for AWS is breadth, a mature migration toolchain, and a funding route your partner can file.

On tooling, AWS has a wide managed-service surface (Aurora and RDS, EKS and ECS, Lambda and App Runner, S3 and the data-lake stack, Bedrock) and a well-paved migration path. Application Migration Service (MGN) does block-level rehost with short cutover windows. Database Migration Service (DMS) and the Schema Conversion Tool (SCT) handle same-engine moves (Postgres to RDS) and engine changes (Oracle or SQL Server to Aurora PostgreSQL) with continuous replication. Migration Hub and Application Discovery Service inventory the estate. DataSync and Transfer Family move bulk data.

The funding piece is the AWS Migration Acceleration Program (MAP). It has three phases: Assess, Mobilize, and Migrate and Modernize. AWS describes it as tools, training, partner expertise and financial investments that offset initial migration costs. Your matched partner files the MAP request when the migration qualifies, and AWS decides the amount. That is what makes a partner-run migration affordable for a startup. See AWS MAP, explained for startups, and how much funding a partner can file.

IIIThe migration journey: six phases

Almost every AWS migration follows the same six-phase arc, and it maps onto the MAP phases. Knowing the shape tells you where the risk sits: the pilot and the cutover, every time.

The most common failure is skipping straight to "let's move servers." Teams that do find the dependency they did not map, the database that will not cut over cleanly and the landing zone they have to retrofit under pressure.

IVRehost vs replatform vs refactor: what to do first

AWS frames migrations as the "7 Rs": retire, retain, rehost, relocate, repurchase, replatform, refactor. For almost every workload the real choice is rehost, replatform or refactor, and the right default is: rehost now, replatform selectively, refactor later.

Rehost (lift and shift) moves the workload as-is onto EC2 with MGN. It is the fastest way off the old platform and the lowest risk per workload, because nothing about the app changes. You carry the old inefficiencies with you until you optimize.

Replatform makes targeted changes that pay back fast: self-managed Postgres to RDS or Aurora, a VM to ECS on Fargate or EKS, a self-hosted queue to SQS. Replatform what is expensive to operate (databases, message brokers, orchestration). Rehost what is cheap to leave alone.

Refactor into Lambda, Step Functions or event-driven services delivers the most long-term value and costs the most up front. Do it after you are stable on AWS, one workload at a time. Refactoring mid-migration is how cutovers slip by quarters.

The other Rs are quick filters during discovery: retire what nobody uses, retain what cannot move yet, and repurchase where a SaaS product beats migrating at all.

VWhat a partner-led migration looks like, and who files what

A partner-led migration is not "hand over your AWS keys and disappear." The partner owns the migration machinery. You own the product decisions.

A vetted partner runs the six phases as a managed engagement: it builds the landing zone, configures and runs MGN, DMS and SCT, writes and rehearses the cutover runbook, runs the waves, and sets up monitoring and cost guardrails. You keep control of which workloads move, in which order, in which windows, and the go/no-go at each gate.

On funding, your matched partner checks whether the migration qualifies for MAP and files the request. AWS approves it and decides the amount. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves. If the migration does not qualify, you can still hire the same partner at its normal rates, or run the move yourself.

CloudRoute is the match, not the migrator. We pick a vetted partner who has done your source-to-target move and introduce you. CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. More on how CloudRoute works.

VIWhat you provide vs what the partner provides

The usual worries about a partner-led migration are losing control and a big internal time sink. Neither holds when the split is clear.

VIIHow long does it take?

There is no single honest number: a five-server SaaS and a 300-VM estate are different projects. The phase shape is consistent, and these are the ranges to plan around.

A small workload (one app, one database, a few servers, like a typical Heroku to AWS migration or a DigitalOcean move): commonly 3–6 weeks end to end. The cutover window itself is often minutes to a couple of hours.

A mid-size estate (10–40 workloads, a few databases, some integrations): plan for 2–4 months, with several cutover waves.

A large or mixed estate (50+ workloads, Oracle or SQL Server with heavy schema conversion, SAP, strict compliance): 6–12+ months is normal. Database engine changes are the long pole. Schema conversion, stored-procedure rewrites and data validation take far longer than moving the app tier.

The biggest schedule risks, in order: schema conversion on an engine change, dependencies that surface mid-wave, an underbuilt landing zone, and cutover windows the business will not accept. A partner who has done your exact move has hit all four before.