Skip to content

AWS Updated 2026-07-04

AWS migration services for small business: what a good engagement looks like

Evaluating AWS migration services for small business? Here is what a competent engagement actually contains — discovery, waves, cutover, ops handoff — and the red flags that predict a bad one.

A good AWS migration engagement for a small business has a recognizable shape: a discovery phase that produces a written inventory, a plan broken into waves with the easiest workloads first, a rehearsed cutover with a rollback path, and a named owner for the environment after go-live. If a provider quotes a price before seeing your servers, or the plan ends on cutover day with nobody accountable for operations afterward, that is the engagement to walk away from.

What you are deciding

You are not really buying “a migration.” You are buying four separate things that often get bundled and blurred: an assessment (what do you actually run, and what should each piece become on AWS), a landing zone (the account structure, networking, and identity setup everything lands in), the move itself (replication, testing, cutover), and day-two operations (patching, backups, monitoring, cost control). Small-business engagements go wrong when one of those four is silently missing — usually the first or the last.

The assessment matters because not everything should be lifted as-is. A ten-server estate typically contains two or three servers that should be retired, one workload that belongs in a managed service like RDS instead of a self-run database VM, and file shares that fit better in a managed store than on an EC2 file server. A provider that quotes “we move all ten servers” without that conversation is optimizing for their own simplicity, not your bill.

Cost mechanics are worth understanding before you sign anything. The migration tooling itself is cheap — AWS Application Migration Service replicates servers at no service charge for a limited free period per server, and you pay for the staging resources it creates. What actually drives the project price is labor: the number of applications, how tangled their dependencies are, how much data has to move, and how much testing your business can tolerate. Run your inventory through the AWS pricing calculator yourself before discovery calls so you can sanity-check the run-rate numbers a provider shows you.

What to check first

Before evaluating anyone, check your own readiness — these gaps make every quote worse:

  • Do you have a server inventory? Even a spreadsheet with hostname, OS, role, and owner. If not, the first paid phase of any honest engagement is building one.
  • Do you know your dependencies? Which app talks to which database, what breaks if the file server moves. Undocumented dependencies are the number one cause of blown cutover weekends.
  • Is anything license-constrained? Windows Server, SQL Server, and vendor apps with hardware-tied licensing change the math significantly.
  • Who runs it after? If the answer is “the same person who ran the server room, part time,” the ops handoff plan matters more than the migration plan.
  • Is there a deadline? A lease ending or hardware dying compresses everything and should be disclosed up front, not discovered mid-project.

How to verify

If a provider has already set up an AWS account for you, or you have one from an earlier attempt, a few commands tell you how seriously it was built:

# Whose account is this, and is it part of an organization?
aws sts get-caller-identity
aws organizations describe-organization

# Is anything running that nobody told you about?
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,Tags]' \
  --output table

# What is the account actually spending?
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

In the console, Migration Hub > Discover > Servers shows whether discovery tooling was ever actually deployed, and Billing and Cost Management > Bills shows whether anyone set up cost visibility. An account with running workloads and zero budgets or alarms configured tells you how the last engagement ended.

The approach

A competent small-business engagement runs in this order:

  1. Discovery with tooling, not just interviews. An agent or agentless collector inventories servers, utilization, and network connections for at least two weeks. The deliverable is a written inventory with a disposition per workload: rehost, replatform, retire, or retain on-premises.
  2. A landing zone before any server moves. Separate accounts for production and non-production, centralized identity, CloudTrail on, a network layout that spans availability zones. See Control Tower and Account Factory for what this looks like done properly — even at small scale, the account structure is the part that is painful to fix later.
  3. A pilot wave of one or two low-risk workloads. This proves the replication tooling, the network path, and the runbook before anything customer-facing moves. Any provider who resists a pilot wave is guessing.
  4. Waves ordered by dependency, not by convenience. Databases and shared services move with, or before, the applications that depend on them. Each wave has a test window and defined success criteria.
  5. A rehearsed cutover with rollback. DNS TTLs lowered in advance, a test cutover into an isolated subnet first, and a written point-of-no-return decision. “We will figure it out on the night” is not a plan.
  6. An operations handoff, in writing. Who patches, who answers alarms, where backups go and who has verified a restore, what the monthly cost review looks like. A baseline alarm set like the one in the CloudWatch alarm baseline should exist before the provider walks away.

When this is the wrong move

Some small businesses should not do a server migration at all. If your estate is one aging server running email and files, replacing it with SaaS (hosted email, a document platform) is cheaper and simpler than recreating it on EC2. If your hardware is two years old and your workloads are static, the financial case for moving now may simply not be there — AWS rewards elasticity and punishes idle capacity. And if a vendor application is the only thing keeping a server alive, ask the vendor about their hosted offering before paying anyone to move it.

Common mistakes

  • Buying a fixed-price migration with no discovery phase. The price was invented; the change orders will not be.
  • Letting the provider own the AWS root account. The account, root credentials, and billing relationship should be yours from day one.
  • Skipping the retire conversation. Paying to migrate servers that should have been decommissioned is the most common avoidable cost.
  • Treating go-live as the finish line. The expensive surprises — oversized instances, missing backups, no alarms — surface in months two and three.

Prevention

  • Insist the statement of work names all four phases: assessment, landing zone, migration, operations handoff.
  • Keep root account ownership, billing, and at least one admin login in your hands throughout.
  • Require a written rollback plan per wave before approving that wave.
  • Ask for the post-migration cost estimate in writing and compare it to the actual bill at 30 and 90 days.
  • Agree before signing who is on the hook when something breaks at 2 a.m. after cutover.

Most small-business migrations fail on the parts that were never scoped — the inventory nobody built and the operations nobody owned. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.