Legacy Parity Book a call

Modernization Studio

Find your kind of system. See how it could run on AWS.

Answer five questions and we'll match your system to one of 19 common legacy types. Each type comes with a modernization path, a target design and the way we prove the new system behaves like the old one.

Your answers stay in your browser. Nothing is sent to us.

Identify your system

The example answers describe a typical mainframe banking system. Change any answer to see new matches.

All 19 system types

Pick any type to see its modernization template. Three are written in full, each with a worked example; the rest show the short version.

Modernization patterns

The patterns behind the templates

Most moves to AWS use one of five patterns, or a mix of them. Each trades speed against how much of the old design you keep. Whichever fits, the new system is proven against the old one before traffic moves.

01Rehost or replatform

Three-tier application

Move a familiar web application onto managed AWS infrastructure and keep most of its structure.

Three-tier application on AWSUsers reach CloudFront, then an Application Load Balancer, then application servers on EC2 in private subnets, which use an RDS database. VPC, private subnets UsersBrowser CloudFrontHTTPS, caching Load balancerALB Amazon EC2App serversAuto Scaling Amazon RDS

Why choose it

  • Fastest path for many existing web applications
  • Little change to application code
  • Clear split of web, application and data tiers

Trade-offs

  • The old design's limits come along
  • You still patch operating systems and runtimes
  • Scaling is coarser than with containers or functions

How we prove parity: record real traffic, replay it against old and new from the same database copy, and compare every response and database change.

Relative cost: medium. Servers run all the time unless scaled down; database size, backups, high availability and data transfer drive the rest.

02Replatform

Containers

Package the application the same way every time and modernize how it ships, without rewriting it first.

Container-based application on AWSUsers reach an Application Load Balancer, which routes to services on Amazon ECS with Fargate; the services use RDS and send logs and metrics to CloudWatch. UsersHTTPS Load balancerALB Amazon ECS on Fargate Web and APIcontainers Workersbackground jobs Amazon RDSdatabase CloudWatchlogs, metrics

Why choose it

  • Repeatable builds and deployments
  • Keeps most of the code as it is
  • Parts can scale on their own when needed

Trade-offs

  • Needs container, networking and pipeline skills
  • Files and sessions kept on the server must move out
  • Small workloads can cost more than expected

How we prove parity: run the container next to the current server on the same inputs, and compare outputs before switching traffic.

Relative cost: medium. Fargate charges for the compute and memory requested; add load balancing, logs, storage, the database and always-on minimum capacity.

03Refactor selected parts

Serverless

Event-driven APIs and jobs on managed services that scale with requests and events.

Serverless application on AWSA client calls API Gateway, which invokes Lambda functions that use DynamoDB and S3; EventBridge triggers background work. Clientweb, mobile API GatewayHTTPS API AWS Lambdafunctions DynamoDBor Aurora Amazon S3files EventBridgeevents, schedules

Why choose it

  • Scales with demand on its own
  • No servers to manage
  • Suits APIs, jobs and event-driven features

Trade-offs

  • Run-time limits and cold starts to plan for
  • Tracing and debugging across functions take work
  • Service-specific design ties you closer to AWS

How we prove parity: build golden-master tests from the legacy code path for each function you extract, and pass them before any traffic moves.

Relative cost: often low for modest or bursty traffic; request volume, run time, data access, logs and reserved capacity raise it.

04Incremental

Strangler fig

Keep the legacy system running and move one capability at a time to new services.

Incremental replacement on AWSUsers reach a routing layer that sends existing capabilities to the legacy system and moved capabilities to new services with their own data. Usersrequests Routing layerALB or API Gatewayroutes by capability Legacy systemwhat has not moved New servicesLambda or ECS New dataRDS, S3

Why choose it

  • No big-bang cutover
  • Value arrives in small releases
  • The team learns before committing to a rewrite

Trade-offs

  • Old and new run, and cost, side by side for a while
  • Routing and data consistency take care
  • Needs a plan to retire the old system

How we prove parity: each capability passes its equivalence tests before its route switches, and the old path stays available as the way back.

Relative cost: medium to high during the transition; it falls as traffic and data move and the old capacity is retired.

05Replatform or refactor Proven in our CardDemo case study

Mainframe batch

Move nightly job chains off the mainframe one job at a time, keeping the order and the files they pass along.

Mainframe batch on AWSA schedule starts a Step Functions workflow that runs the jobs in order as AWS Batch or ECS tasks; jobs read and write files in S3 and records in Aurora PostgreSQL. ScheduleEventBridge Step Functionsruns jobs in order,stops on failure AWS Batch or ECS tasks Post transactions Calculate interest Statements Amazon S3daily files AuroraPostgreSQL

Why choose it

  • Batch jobs read and write files, so old and new compare record by record
  • One job moves at a time, in the existing order
  • Leaves the screens and data until the jobs that use them have moved

Trade-offs

  • Mainframe number formats and sort order must be converted exactly
  • Jobs that share files with the mainframe need a sync during the transition
  • The batch window must still fit

How we prove parity: run old and new jobs on the same input files and compare every output record. We did exactly this for CardDemo's daily posting and interest jobs.

Relative cost: low to medium. Jobs run and are billed only during the batch window; storage and the database run all the time.

Illustrative patterns, not a deployment blueprint or a quote. The right design, security controls and cost depend on your workload. Costs are relative, not dollar figures; the AWS Pricing Calculator gives estimates for a specific design. Diagrams are our own; AWS service names identify services only.

Templates are conceptual starting points written by Legacy Parity, with links to public AWS documentation. Service names and capabilities were last reviewed in October 2026. See the five patterns behind the templates, and the demos for the systems we are modernizing in the open.