SaaS Migration Playbook: Moving Legacy Software to Cloud 2026

If you are still running a Windows Server 2016 box in a closet somewhere, or paying six figures a year for Oracle Database licenses that support an app built in 2009, you already know the pain. Your customers want API integrations, mobile access, and real-time collaboration. Your engineering team spends 40% of their time on infrastructure maintenance instead of shipping features. And every quarter, the gap between what your product does and what competitors offer gets wider.

The economics have shifted decisively. On-premises infrastructure that cost $50,000 per year in 2020 now costs $75,000 or more thanks to hardware refresh cycles, electricity costs, and the labor shortage in ops roles. Meanwhile, the equivalent cloud infrastructure runs $2,000-$5,000 per month with zero hardware management. That is not just a cost savings. It is a fundamentally different business model where you pay for what you use and scale on demand.

But migration is not just "lift and shift." That approach failed spectacularly for enterprises in 2018-2020, and it will fail again today. Moving a legacy monolith to EC2 instances without rearchitecting it gives you all the cloud costs with none of the cloud benefits. You need a real strategy, and that is exactly what this playbook provides.

Every component of your legacy system needs its own migration strategy. AWS originally defined 6 R's, and they remain the best framework for categorizing your approach. The key is that you will likely use multiple strategies across different parts of your application.

Rehost (Lift and Shift)

Move your application as-is to cloud VMs. This works for components that are already well-architected but just need better infrastructure. Think: a Java application running on Tomcat that simply needs to move from physical servers to EC2 or Azure VMs. Cost savings: 20-30%. Timeline: 2-4 weeks per component. Use this when you need quick wins to build momentum.

Replatform (Lift, Tinker, and Shift)

Make targeted optimizations during migration without changing core architecture. For example, swap your self-managed MySQL for Amazon RDS, or move from IIS to containerized deployments on ECS. Cost savings: 30-50%. Timeline: 4-8 weeks per component. This is the sweet spot for most database and middleware layers.

Refactor (Re-architect)

Restructure existing code to be cloud-native. Break monolithic modules into services, add proper API boundaries, implement event-driven patterns. This is where the real SaaS transformation happens. Cost of refactoring a typical module: $40,000-$120,000. Timeline: 2-4 months per major module. Worth it for your core business logic.

Rearchitect

Completely redesign the application using cloud-native patterns from scratch, while preserving business logic and data. You might rebuild a legacy batch processing system as an event-driven serverless architecture using AWS Lambda, Step Functions, and EventBridge. Timeline: 4-8 months. Reserve this for systems where the current architecture is fundamentally incompatible with cloud patterns.

Rebuild

Start from zero. Throw away the existing codebase and build new. This sounds extreme, but for a 15-year-old VB.NET application with no tests and spaghetti code, a rebuild in modern TypeScript or Go can actually be faster than trying to refactor. Timeline: 6-12 months for a full rebuild. Cost: $200,000-$600,000 depending on complexity.

Replace (Retire)

Kill the component and buy a SaaS alternative. Your custom-built CRM from 2012? Replace it with HubSpot or Salesforce. Your homegrown reporting engine? Replace it with Metabase or Looker. This is often the smartest move for non-core functionality. If you are curious about the cost implications of modernization versus replacement, check out our detailed breakdown of legacy modernization costs.

Before you touch a single line of code, you need a complete picture of your current system. Most migration projects fail not because of technical complexity but because teams discover dependencies and requirements mid-flight that blow up their timeline. Spend 4-6 weeks on assessment. It will save you months later.

Dependency Mapping

Start with runtime dependency analysis, not just reading code. Tools like Dynatrace, AppDynamics, or even open-source options like OpenTelemetry can map actual call patterns between services. You will discover connections nobody documented: that nightly batch job that writes to a shared folder that three other systems read from, or the stored procedure that six different applications call.

• Network-level mapping: Use AWS Migration Hub or Azure Migrate to discover all servers, their communication patterns, and resource utilization over 30+ days
• Application-level mapping: Instrument your code with distributed tracing to map service-to-service calls, database queries, and external API dependencies
• Data flow mapping: Document every ETL job, file transfer, shared database, message queue, and integration point

Data Inventory

Catalog every database, file share, blob storage, and data warehouse. For each data store, document: size (current and growth rate), schema complexity, referential integrity constraints, encryption requirements, and retention policies. A 500GB Oracle database with 2,000 stored procedures is a very different migration challenge than a 50GB PostgreSQL database with clean ORM access patterns.

Compliance Requirements

This is where migrations get killed if you do not plan ahead. Document every compliance framework that applies: SOC 2, HIPAA, PCI-DSS, GDPR, CCPA, FedRAMP. Map which data falls under which regulation. Identify data residency requirements that constrain your cloud region choices. For healthcare applications, you need BAAs (Business Associate Agreements) with your cloud provider before any PHI touches their infrastructure.

Build a migration readiness scorecard for each component: technical complexity (1-5), business criticality (1-5), compliance sensitivity (1-5), and team capability (1-5). Components with low complexity and low criticality go first. They build team confidence and establish patterns that accelerate later, harder migrations.

The two dominant patterns for executing a migration are the strangler fig pattern (gradual replacement) and big bang (switch everything at once). Your choice depends on system size, risk tolerance, and team capacity.

Strangler Fig Pattern

Named after the tropical fig that grows around a host tree and eventually replaces it, this pattern lets you incrementally replace legacy functionality with cloud-native services. You place a routing layer (an API gateway or reverse proxy) in front of your legacy system. New features get built in the cloud. Existing features get migrated one by one. Traffic gradually shifts from old to new until the legacy system handles nothing and can be decommissioned.

This is the right choice for:

• Applications with 50+ active users who cannot tolerate extended downtime
• Systems where you need to maintain feature parity during migration
• Teams that need to deliver new features while migrating (which is almost everyone)
• Enterprise applications where a failed migration has severe business consequences

Implementation: Use Kong, AWS API Gateway, or even Nginx as your routing layer. Start by routing all traffic through the gateway to the legacy system. As you build cloud replacements for each endpoint or feature, update routing rules to point to the new service. Keep the legacy endpoint as a fallback during a validation period. Once metrics confirm the new service handles traffic correctly, remove the legacy route.

Big Bang Migration

Migrate everything at once over a maintenance window. This works for smaller applications (under 20,000 lines of code) with limited user bases, or for internal tools where a weekend of downtime is acceptable. The advantage is simplicity: you do not maintain two systems in parallel. The risk is obvious: if something goes wrong, your rollback plan needs to be bulletproof.

For most enterprise SaaS migrations, the strangler fig pattern is the correct choice. The extra complexity of running two systems in parallel is worth the risk reduction. We have seen too many big bang migrations turn into multi-week outages because of unexpected data inconsistencies or missed edge cases. For more guidance on choosing the right approach for your provider, see our guide on how to migrate between cloud providers.

Database migration is where most cloud migrations get stuck. Your application code can be refactored incrementally, but your data needs to move correctly, completely, and with minimal downtime. Here is how to handle the most common scenarios.

Oracle/SQL Server to PostgreSQL or Aurora

This is the most common enterprise migration path. Oracle licenses alone can cost $47,500 per processor per year (Enterprise Edition). Moving to Aurora PostgreSQL drops that to roughly $3,000-$8,000 per month for equivalent performance, with no license fees. The savings fund the entire migration within 12-18 months.

The challenges are real though. Oracle PL/SQL and T-SQL stored procedures need rewriting. Oracle-specific features like materialized views, database links, and advanced partitioning require alternative implementations. Use AWS Schema Conversion Tool (SCT) to automate 60-70% of schema translation, then manually handle the rest.

Zero-Downtime Migration with AWS DMS

AWS Database Migration Service enables continuous replication from your source database to the target. The process:

• Full load: DMS copies all existing data from source to target (hours to days depending on size)
• Change data capture (CDC): DMS continuously replicates changes from source to target in near-real-time
• Validation: Compare row counts, checksums, and sample data between source and target
• Cutover: Stop writes to source, let CDC catch up (seconds), switch application connection strings to target

For PostgreSQL-to-PostgreSQL migrations or MySQL upgrades, pgloader is a faster alternative. It handles type conversions, schema transformations, and can migrate a 200GB database in under 4 hours on decent hardware. For a deep dive into specific database strategies, our database migration strategies guide covers the tools and patterns in detail.

Data Validation Is Non-Negotiable

Never trust a migration without validation. Build automated comparison scripts that verify: row counts per table, checksum comparisons on critical columns, referential integrity checks, and business logic validation (e.g., "total revenue in the orders table matches between source and target"). Run these continuously during CDC replication and as a final gate before cutover.

Converting a single-tenant legacy application into a multi-tenant SaaS platform is one of the highest-value transformations you can make. It changes your cost structure from linear (one deployment per customer) to logarithmic (shared infrastructure serves all customers). But it requires careful architectural decisions.

Shared Database with Tenant Isolation

The most common pattern for B2B SaaS: one database, every table has a tenant_id column, and row-level security (RLS) in PostgreSQL ensures tenants can never see each other's data. This is the cheapest to operate and simplest to maintain. Works well for up to 1,000 tenants with similar data volumes.

Implementation with PostgreSQL RLS:

• Add tenant_id to every table as a non-nullable foreign key
• Create RLS policies that filter on tenant_id matching the current session variable
• Set the tenant context at connection time in your application middleware
• Add composite indexes on (tenant_id, primary_key) for every table

Schema-Per-Tenant

Each tenant gets their own PostgreSQL schema within a shared database. Better isolation than shared tables, easier to handle tenants with custom schema extensions, and simpler to export/delete a single tenant's data (relevant for GDPR). Drawback: schema migrations must apply to hundreds or thousands of schemas, which requires careful orchestration. Tools like Flyway or Atlas can handle this with tenant-aware migration scripts.

Authentication Modernization: LDAP/AD to OAuth2/OIDC

Legacy enterprise apps typically authenticate against Active Directory via LDAP. Cloud SaaS needs OAuth 2.0 and OpenID Connect for SSO, social login, and API access. The migration path:

• Phase 1: Deploy an identity provider (Auth0, Keycloak, or AWS Cognito) that federates with existing AD. Users authenticate the same way, but your app receives JWT tokens instead of LDAP sessions.
• Phase 2: Migrate user profiles and permissions from AD attributes to the new IdP's user store. Map AD groups to OIDC claims and RBAC roles.
• Phase 3: Add modern auth flows: magic links, MFA, social login, SAML SSO for enterprise customers. Remove direct LDAP dependency.

Budget 4-8 weeks for auth migration. It touches every part of your application and requires extensive testing across all user roles and permission levels. Do not underestimate this.

Your legacy deployment process probably involves someone manually copying files to a server, or at best, a Jenkins job that nobody dares to modify. Cloud-native SaaS demands automated, repeatable, and fast deployments. Here is your target state.

CI/CD Pipeline Architecture

Use GitHub Actions, GitLab CI, or CircleCI. The pipeline stages:

• Build: Compile code, run unit tests, build Docker images (target: under 5 minutes)
• Test: Integration tests against ephemeral environments, security scanning with Snyk or Trivy, schema migration dry-runs (target: under 10 minutes)
• Deploy to staging: Automatic deployment to a staging environment that mirrors production. Run end-to-end tests with Playwright or Cypress.
• Deploy to production: Blue-green or canary deployment with automatic rollback on error rate spikes. Use ArgoCD for Kubernetes or AWS CodeDeploy for ECS.

Infrastructure as code is mandatory. Use Terraform or Pulumi to define all cloud resources. Every environment (dev, staging, production) should be reproducible from code in under 30 minutes. This eliminates the "works on my machine" problem and makes disaster recovery trivial.

Cost Modeling: On-Prem TCO vs. Cloud Monthly

The honest comparison most vendors will not give you:

• On-prem TCO (typical enterprise app): Hardware ($15,000-$40,000 every 3-5 years), OS licenses ($5,000-$15,000/year), database licenses ($20,000-$100,000/year), backup infrastructure ($5,000-$10,000/year), ops staff allocation (0.5-1.0 FTE at $80,000-$150,000/year), facility costs ($5,000-$15,000/year). Total: $80,000-$250,000 per year.
• Cloud monthly (equivalent workload): Compute ($1,500-$4,000/month), managed database ($800-$3,000/month), storage and networking ($200-$800/month), monitoring and logging ($100-$500/month), CI/CD tooling ($200-$500/month). Total: $2,800-$8,800/month or $34,000-$106,000/year.

Cloud costs are typically 40-60% lower than on-prem TCO when you include all hidden costs. But the real value is not cost reduction. It is the ability to scale instantly, deploy multiple times per day, and eliminate unplanned downtime from hardware failures. Your engineering team reclaims 30-50% of their time previously spent on infrastructure maintenance.

A typical enterprise legacy-to-cloud SaaS migration takes 12-24 months. That is not a guess. It is based on dozens of migrations we have executed and observed across companies ranging from 20 to 500 employees. Here is a realistic timeline breakdown:

• Months 1-2: Assessment and planning. Dependency mapping, data inventory, compliance review, strategy selection for each component. Deliverable: migration roadmap with prioritized component list.
• Months 2-4: Foundation. Set up cloud accounts, networking (VPC, VPN to on-prem), CI/CD pipelines, infrastructure-as-code, monitoring stack. Establish the landing zone that all migrated services will deploy into.
• Months 4-8: Core migration. Database migration, authentication modernization, and first 2-3 application modules migrated using strangler fig pattern. First production traffic hitting cloud services.
• Months 8-14: Bulk migration. Remaining application modules migrated systematically. Multi-tenancy implementation if converting to SaaS. Performance optimization and load testing.
• Months 14-18: Hardening and cutover. Legacy system fully decommissioned. Disaster recovery testing. Security audit. SOC 2 or relevant compliance certification. Full production traffic on cloud infrastructure.
• Months 18-24: Optimization. Cost optimization (right-sizing instances, reserved instances, spot instances for non-critical workloads). Feature development velocity ramps up as team builds confidence with new platform.

The biggest risk factor is not technology. It is organizational. Teams that try to migrate while simultaneously building new features with the same engineers always blow their timelines. Dedicate a focused migration team, even if it is just 2-3 engineers, and protect their time ruthlessly.

Total investment for a typical migration (mid-market SaaS company, 100K-500K lines of code): $300,000-$800,000 including tooling, cloud spend during parallel operation, and engineering time. ROI typically hits break-even within 18-24 months through reduced infrastructure costs, faster feature delivery, and eliminated license fees. After that, the savings compound annually.

If your legacy application is holding your business back and you are ready to build a migration plan tailored to your specific architecture, team, and budget, we can help. Book a free strategy call and we will map out your first 90 days together.