Cloud Migration for Small Business: A Practical Guide from a San Diego Cloud Consultant

The Real Reason Small Business Cloud Migrations Fail

Most small business cloud migrations do not fail because the technology is too hard. They fail because the business never decided what problem the migration was supposed to solve. The result is a lift-and-shift that ends up costing more than the on-premises environment it replaced, with none of the agility the business thought it was buying.

I have spent years working in cloud architecture and cybersecurity, and the pattern is consistent. A business signs up for AWS or Azure because a peer said it was better. They migrate a few servers as-is. They discover the monthly bill is higher than the hardware it replaced. They blame the cloud and start looking for an exit.

The cloud is not expensive. Misused cloud is expensive. The difference is understood before the first resource is provisioned, not after.

Five Questions to Answer Before You Migrate Anything

Before you open an AWS account, sit down and answer these five questions in writing. If you cannot answer them, you are not ready to migrate.

What problem am I trying to solve? Reducing hardware refresh costs, enabling remote work, scaling for seasonal demand, improving disaster recovery, meeting a compliance requirement, or something else. These lead to different migration patterns. A migration driven by disaster recovery looks different from a migration driven by cost reduction.

What is in scope? Not every workload belongs in the cloud. A legacy application that runs fine on a five-year-old server and that nobody touches does not need to move. The systems that benefit most from the cloud are the ones that scale, that support remote access, or that need high availability.

What is my runway? A cloud migration is a project, not a purchase. For a typical small business, the migration itself takes three to six months. During that window, you are running on-premises and cloud infrastructure in parallel, which means you are paying for both. Budget for the overlap.

What happens if I have to move back? Vendor lock-in is real. Some cloud services are portable. Some are not. Before you commit to a managed database service or a proprietary API gateway, know what the exit looks like.

Who is going to run this? The cloud does not eliminate operations work. It changes what operations looks like. If nobody in your business knows how to read a CloudWatch log or configure a security group, either train someone or hire someone. Unmanaged cloud is not cheap cloud. It is abandoned cloud.

The Six Migration Patterns and When to Use Each

AWS documented six migration patterns years ago, and they still describe the real choices. For a small business, the pattern you pick for each workload matters more than the cloud provider you pick.

Rehost (lift and shift). Move the workload to the cloud without changing it. Fastest to execute. Worst return on investment. Use this only for workloads you plan to retire within 18 months or for applications that genuinely do not need to change.

Replatform (lift and optimize). Move to the cloud and adopt a managed service for one component, typically the database. You keep the application code, but you stop running the database on a VM you have to patch. Best value-to-effort ratio for most small business workloads.

Repurchase. Replace the application with a Software-as-a-Service alternative. Your on-premises email server becomes Microsoft 365. Your file server becomes OneDrive or SharePoint. Your CRM becomes HubSpot or Salesforce. This is the most common small business cloud migration, and it is often the right answer.

Refactor. Rewrite the application to take advantage of cloud-native services. Highest effort. Highest upside. Rarely justified for small business internal workloads. Sometimes justified for a product you sell to customers.

Retain. Keep it on-premises. Not every workload needs to move. A workload with low usage, predictable requirements, and no connectivity dependencies may be cheaper to run on existing hardware until that hardware is due for replacement.

Retire. Turn it off. Every migration surfaces workloads that nobody actually uses. Deleting them is the cheapest and fastest part of any migration.

AWS, Azure, or Google Cloud for Small Business

I get asked this every time. The honest answer is that for most small businesses, the choice does not matter nearly as much as the buyer thinks it does. All three providers can run the same workloads at similar prices. The right choice depends on three factors.

What does your team already know? If your outsourced IT provider is a Microsoft partner and works in Azure all day, that is your default. Fighting that inertia to save a few dollars per month on the other platform is a bad trade.

What are you integrating with? If your business runs on Microsoft 365 and Windows, Azure has tighter integration. If you are serving AWS-hosted customers or contractors, AWS makes sense. If you are heavily in Google Workspace, Google Cloud has fewer friction points.

What does your compliance picture look like? If you need FedRAMP High or CMMC handling of CUI, your options narrow. AWS GovCloud and Azure Government are the mature answers there. Google Cloud has offerings but a smaller footprint in the defense community.

For a typical San Diego small business with no specialized compliance needs, I default to AWS for infrastructure workloads because of its breadth of services and mature small business pricing, and Microsoft 365 for productivity. That is not a universal recommendation. It is a starting point that you revise based on the answers above.

The Security Baseline You Cannot Skip

Cloud migrations fail security audits for the same reasons they fail financially. The business treated the cloud as a data center with a new address and never implemented controls that take advantage of what the cloud actually provides. Here is the baseline I implement on every small business cloud environment I build.

Multi-factor authentication on the root account, period. The AWS root account or Azure global admin can destroy everything you just built. MFA is not optional. Use a hardware key if you can, not a phone-based authenticator, because phones get lost and swapped.

Separate administrative accounts from daily-use accounts. Do not use the root account for day-to-day work. Create IAM users or Entra ID accounts with the minimum privileges needed and use those.

Logging turned on from day one. AWS CloudTrail and Azure Activity Log are effectively free and they record every administrative action in your tenant. Enable them before you do anything else. You cannot investigate an incident with logs you never collected.

Encryption on by default. S3 buckets, EBS volumes, RDS databases, Azure storage accounts, and every managed database service offer encryption at rest at no additional cost. Turn it on. Encrypt data in transit with TLS.

Network boundaries that mean something. Default virtual private cloud configurations are permissive. Do not run production workloads in a default VPC. Build a VPC with public and private subnets, put databases in the private subnet, and expose only what needs to be exposed.

Backups stored separately from the source. A cloud backup stored in the same account as the source it protects is not really a backup. Use a separate account or a separate region, so a compromise of one account does not take the backups with it.

Monthly billing review. A small business should look at the cloud bill every month. Not to argue with the provider, but to spot waste and catch the resource someone provisioned and forgot.

A Realistic Timeline and Budget

For a San Diego small business moving a typical mixed workload of one file server, one application server, one database, and a handful of SaaS integrations to AWS, here is what a responsible migration looks like.

Weeks 1 and 2: Discovery and design. Inventory every workload. Interview the people who use them. Pick the migration pattern for each. Produce a target architecture diagram.

Weeks 3 and 4: Foundation. Set up the AWS or Azure account. Establish the security baseline above. Configure identity and access management. Set up logging, billing alerts, and tagging standards.

Weeks 5 to 8: First workload. Migrate one low-risk workload first. Often this is a file share or a static website. Validate the pattern. Document what you learned.

Weeks 9 to 16: Remaining workloads. Migrate the rest in order of risk and dependency. Run on-premises and cloud in parallel until each cutover is validated.

Weeks 17 and 18: Decommissioning. Shut down on-premises systems. Cancel the hardware support contracts. Recover whatever capital you can from retired equipment.

Consulting cost for a migration like this, done carefully, is typically $12,000 to $30,000 depending on scope. Ongoing AWS spend for a small business of 10 to 25 employees typically settles in the range of $400 to $1,500 per month after optimization, which is often less than the total cost of ownership of the equivalent on-premises environment once you factor in hardware refresh, power, cooling, and maintenance.

When Cloud Is Not the Right Answer

Not every small business should be in the cloud. If your business runs two servers that are fully depreciated, that rarely fail, and that do not need to scale, and you have the internal expertise to keep them running, the cloud is a solution looking for a problem. Moving for the sake of moving is not strategy.

The cloud pays off when your business needs elasticity, remote access, high availability, geographic distribution, or when your hardware refresh cycle is coming up anyway. If none of those apply, staying on-premises is a defensible choice for another few years.

Where To Start This Month

If you are considering a cloud migration, two tasks this month will give you a real picture of whether to proceed.

First, run a workload inventory. List every server, every database, every application, every SaaS tool you pay for. For each one, note the business purpose, the current cost, and whether it is critical to the business.

Second, for each workload, write one sentence describing the cloud migration pattern you would use. If the answer for most of them is retain or retire, the cloud may not be your next move. If the answer for most of them is replatform or repurchase, you have a real opportunity.

That inventory and pattern mapping is the foundation of every migration plan I write. Without it, every decision downstream is guesswork.