Modernizing Legacy Software for the Cloud: ISV Playbook

Why Modernization Is Strategically Necessary for ISVs

Legacy software products are fighting on three fronts simultaneously: on the cost side, on-premises infrastructure maintenance costs are rising while cloud-native competitors operate with lower fixed costs and greater agility. On the competitive side, enterprise customers increasingly demand cloud deployment, SaaS models, and Marketplace-available solutions as purchase criteria. And on the technology side, technical debt prevents rapid innovation cycles — every new feature requires disproportionate effort.

For ISVs, modernization means not just technological renewal, but simultaneously the opportunity for business model transformation: from one-time license fees to recurring SaaS revenue, from local customers to global Marketplace reach.

The Four Modernization Paths at a Glance

Path 1: Lift-and-Shift (Rehosting)

The simplest modernization path: the existing application is migrated to AWS infrastructure without code changes. On-premises servers are replaced by EC2 instances, local databases by Amazon RDS.

AWS Implementation

1. Infrastructure assessment: Inventory existing server landscape (AWS Application Discovery Service), map dependencies, determine sizing for EC2 instance types.
2. Network architecture: VPC with public and private subnets, Security Groups as firewall replacement, NAT Gateway for outbound traffic from private subnets.
3. Data migration: AWS Database Migration Service (DMS) for database migrations. AWS Schema Conversion Tool for database platform changes.
4. Server migration: AWS Application Migration Service (MGN) for automated server replication and cutover with minimal downtime.
5. Validation and go-live: Parallel operation, performance comparison, cutover, monitoring setup with Amazon CloudWatch.

After Lift-and-Shift: the product runs in the cloud but is not yet a SaaS product. It is the starting point for further modernization.

Path 2: Containerization (Replatforming)

Containerization brings substantial benefits without complete re-architecting: consistent deployment environments, easier scaling, better resource utilization. For ISVs, Docker + ECS/EKS provides the foundation for multi-tenant deployments.

1. Containerize the application: Create Dockerfile, run local tests, use multi-stage builds for optimal image sizes. Store container image in Amazon ECR (Elastic Container Registry).
2. Choose orchestration platform: Amazon ECS (simpler, less overhead) for simpler workloads; Amazon EKS (Kubernetes) for complex microservices architectures or when customers bring Kubernetes expertise.
3. Service definition: Create ECS Task Definitions or Kubernetes Deployments + Services. Define resources (CPU, memory) and scaling rules.
4. Load balancing: Application Load Balancer (ALB) for HTTP/HTTPS traffic, with path-based routing for multiple services on one ALB.
5. CI/CD pipeline: AWS CodePipeline + CodeBuild for automated build and deployment. Every git push automatically triggers build, test, and deployment.

When ECS, When EKS?

Amazon ECS (Elastic Container Service)

AWS-native container orchestration. Simpler to operate, less configuration overhead, tight AWS service integration. Recommended for ISVs without a dedicated platform engineering team.

Amazon EKS (Elastic Kubernetes Service)

Managed Kubernetes. Higher initial effort, but more portable (on-premises + multi-cloud) and with a larger ecosystem. Recommended when customers require Kubernetes deployments in their own account (silo model).

AWS Lambda (Serverless)

For event-driven workloads and stateless microservices. Ideal complement to container architectures for background jobs, webhooks, and API handlers.

Path 3: The Strangler Fig Pattern

The Strangler Fig Pattern enables gradual replacement of a monolith without interrupting ongoing operations. Named after the strangler fig tree (Ficus) that slowly engulfs its host tree and eventually replaces it.

Implementation with Amazon API Gateway

1. API inventory: Document all API endpoints of the monolith. Prioritize: which endpoints change most frequently? Which new features are planned? These are the first candidates for microservices.
2. Set up API Gateway: Amazon API Gateway as front door for all API requests. By default, all requests are forwarded to the monolith.
3. Develop first microservice: Reimplement one endpoint (e.g., user registration) as a standalone Lambda service or ECS service. Fully isolated, with its own database.
4. Redirect traffic: Reroute the API Gateway route for this endpoint to the new microservice. The monolith implementation remains as a fallback for now.
5. Repeat until monolith is empty: Iteratively port more endpoints. At the end, the monolith is decommissioned — it has been emptied of functionality.

Critical for success: database decomposition. Each microservice needs its own database — the shared database anti-pattern (all microservices use the same DB) prevents independent deployments and scaling.

Path 4: Full Re-Architecting

The most ambitious path: the application is rebuilt from scratch as a cloud-native SaaS product. Greenfield development with modern architecture principles: event-driven architecture, microservices, serverless-first.

Full Re-Architecting is only appropriate when:

• The level of technical debt makes incremental modernization uneconomical
• Sufficient resources exist for parallel development (new architecture + maintaining the legacy system)
• The business model is fundamentally changing (e.g., from on-premises license to multi-tenant SaaS)
• New markets are to be addressed that the existing product technically cannot serve

Marketplace Integration After Modernization

Modernization is also the optimal time for AWS Marketplace integration. After containerization or the Strangler Fig process, the technical prerequisites for a Marketplace listing are typically met:

1. SaaS subscription integration: Implement a landing page for new Marketplace buyers. AWS passes a registration token; the application processes it and creates the customer account.
2. Metering Service: Call the aws-marketplace:MeterUsage API for usage-based billing. The modernized architecture (Lambda/ECS) significantly simplifies integration.
3. Activate multi-tenancy: The Marketplace listing becomes the trigger for implementing multi-tenancy if not already present. Every Marketplace buyer is a new tenant.

Frequently Asked Questions

What is the Strangler Fig Pattern?

The Strangler Fig Pattern is a modernization strategy in which new microservices gradually replace the functionality of a monolith. New features are developed exclusively as microservices; existing features are ported by priority. An API Gateway routes requests either to the monolith or to the new service.

When is Lift-and-Shift the right choice?

Lift-and-Shift is appropriate when rapid migration without code changes is required, on-premises infrastructure maintenance needs to be reduced, or as a first step in a multi-stage modernization strategy.

How long does a typical ISV modernization take?

Lift-and-Shift: 4–12 weeks. Containerization: 3–6 months. Strangler Fig: 12–36 months (depending on monolith size). Full Re-Architecting: 18–48 months.

Can I continue developing during modernization?

Yes — this is even necessary. The Strangler Fig Pattern is explicitly designed to parallelize modernization and ongoing feature development. Only Full Re-Architecting typically requires a "freeze" phase for the legacy system.

How do I integrate a modernized product into the AWS Marketplace?

After modernization, the product must meet AWS Marketplace API requirements: SaaS subscription integration for buyer authentication, AWS Marketplace Metering Service for usage-based billing, and a seller registration in the AWS Marketplace Management Portal.

Storm Reply: ISV Modernization Partner with AWS Expertise

Storm Reply is an AWS Premier Consulting Partner in the DACH region with the AWS Migration Competency and AWS DevOps Competency. We have accompanied numerous ISVs in modernizing their software products on AWS — from the initial assessment phase to the Marketplace listing.

Our ISV assessment includes: technical analysis of the existing architecture, evaluation of all four modernization paths, business case calculation (TCO old vs. new), and a concrete implementation roadmap. Typical duration: 2–3 weeks.