This article is based on a piece originally published on InfoQ. The methodology and reference architecture described here were developed by a practitioner with experience migrating Unisys mainframe applications to open systems.
The Mainframe Conundrum
If your organization runs a Unisys ClearPath mainframe, you may have assumed that cloud computing is simply not an option. Common objections include concerns about transaction throughput, architectural incompatibility, and sheer migration complexity. For many years those concerns were well-founded. But AWS has matured significantly as a platform, and a structured, least-change migration approach now makes it practical to move Unisys workloads to AWS without a ground-up rewrite.
This article lays out a five-step methodology for doing exactly that, along with a reference architecture showing how Unisys ClearPath Libra (Burroughs lineage) and ClearPath Dorado (Sperry lineage) components map to AWS services.
A Brief History of Unisys Mainframes
Unisys traces its lineage to two separate computing dynasties. The Burroughs Corporation—itself descended from the American Arithmometer Company founded in 1886—merged with the Sperry Corporation in 1986 to form Unisys. Sperry had its own roots going back to 1910. Together, their predecessor companies produced BINAC and UNIVAC, among the first general-purpose commercial computers.
When Burroughs and Sperry merged, each brought its own mainframe line and customer base. Attempts to unify the two architectures were only partially successful, and both survive today:
- ClearPath Libra — descended from the Burroughs line, using MCP (Master Control Program) as its operating system and DMSII as its primary database.
- ClearPath Dorado — descended from the Sperry line, using OS 2200 and RDMS.
Despite their differences, both families share core mainframe characteristics: high transaction throughput, proprietary operating systems, tight coupling between OS and database, and a deep pool of institutional knowledge that organizations are understandably reluctant to discard.
Why Cloud Computing Is Now Viable for Mainframe Workloads
Early skepticism about cloud computing among mainframe shops was rational. In the mid-2000s, cloud infrastructure could not reliably handle the transaction volumes, security posture, or data-integrity guarantees that mainframe customers expected. That calculus changed as AWS added enterprise-grade services.
Unisys itself developed x86-compatible underpinnings so that ClearPath Libra and Dorado workloads could run on standard open-systems hardware. That move validated the concept but left applications running on antiquated, proprietary OS and database stacks with a shrinking talent pool. It also stopped short of fully exploiting modern cloud capabilities.
The more effective path is a transformative migration: reuse as much original application source code as possible while replacing the proprietary OS, database, and runtime with modern AWS-native equivalents. This approach:
- Preserves decades of business logic embedded in existing code.
- Reduces project cost and risk compared to full rewrites or package replacements.
- Leaves the migrated application recognizable enough for existing staff to maintain.
- Enables integration with modern technologies—mobile, analytics, APIs—that proprietary mainframe stacks cannot easily support.
Migrating Unisys Applications to AWS in 5 Steps
The following methodology extends a proven open-systems migration process to the AWS platform. Think of it as the same recipe with a few new ingredients.
Step 1: Discover
Catalog and analyze everything in your existing environment: applications, programming languages, databases, networks, platforms, JCL or WFL job streams, and operational processes. Document interrelationships between applications and all external integration points—batch feeds, real-time interfaces, file transfers, and third-party services.
Use automated analysis tools wherever possible and store all findings in a central repository. This inventory becomes the input to migration rules in your automated transformation engine. Those rules will be refined continuously throughout the project, so invest in making the repository comprehensive from the start.
Step 2: Design
Analyze source code, data structures, end-state requirements, and available AWS components to produce a detailed architecture. The design document should cover:
- AWS component types and instance sizing based on transaction volumes and batch windows.
- Language conversion strategy: COBOL is almost always migrated automatically; languages such as Algol, MASM, AB Suite (LINC), and BIS (MAPPER) typically require replacement or custom development.
- Data migration strategy: flat files may stay flat or be converted to relational; hierarchical data should be converted to relational using ETL tooling or purpose-built conversion programs.
- Integration design for external systems and stateless service exposure of legacy business functions.
- Third-party tooling decisions—specifically, which mainframe emulation or transformation tools minimize the volume of hand-coded changes.
- Planning for future requirements such as high-availability topology, disaster recovery, and regulatory compliance.
Choose migration tools that require the least amount of manual change to source code. The fewer hand-edits required, the lower the cost and risk of the project.
Step 3: Modernize
Modernization is an iterative, largely automated process. An automated transformation engine applies the migration rules defined in Step 2 to produce modified source code. If the code compiles cleanly, it proceeds to unit test. If it does not, developers diagnose the errors, update the migration rules, and re-run the affected programs. Fixes discovered for one program are often applicable across many others—economies of scale that accelerate the process over time.
In parallel with code transformation:
- Developers write replacement source for legacy components that have no automated migration path.
- Data specialists build out and validate target database schemas.
- Static (non-changing) data can be migrated to the target database and file systems while code migration is still in progress.
- Dynamic data—records that change frequently—is held back for migration during the production cutover window.
Step 4: Test
Testing focuses on the code that has actually changed, not every line in the system. Key areas of test focus include:
- Data access paths and query results after database migration.
- Sort routines that may behave differently under ASCII collation versus the EBCDIC collation used on mainframes.
- Code modified to accommodate data type changes between legacy and target platforms.
- All newly developed replacement code.
- Load and stress testing to validate that AWS instance configurations can sustain peak transaction volumes.
A common challenge is the absence of existing test scripts and documentation for legacy mainframe applications. Budget time to develop a proper test suite. This investment pays dividends: the scripts can be reused for regression testing the application throughout its life on AWS, supporting CI/CD practices that were not practical on the mainframe.
Step 5: Implement
Many implementation activities can run in parallel with earlier phases rather than waiting until the end. These include:
- Provisioning and configuring AWS component instances (VPC, EC2, RDS, ELB, etc.).
- Installing and configuring any mainframe emulation or runtime middleware.
- Migrating and validating static data.
- Establishing monitoring, alerting, and operational runbooks.
Once tested applications and dynamic data migration are ready, cutover to production can be completed. The specifics—whether environments are replicated, repurposed, or run in parallel—depend on application characteristics, acceptable downtime windows, and organizational standards.
Reference Architecture: Mapping Unisys Components to AWS
The diagrams below show how ClearPath Libra and ClearPath Dorado components map to their AWS equivalents. Treat these as a general guideline; every environment has unique requirements that will influence the final architecture.
Key AWS Components and Their Mainframe Equivalents
Your Cloud Environment: Amazon VPC
Amazon Virtual Private Cloud (VPC) provides a logically isolated network within AWS. Think of it as the security perimeter around all your migrated systems. You control IP address ranges, subnet design, route tables, and network gateways. Both IPv4 and IPv6 are supported. Your VPC replaces the private network infrastructure of the mainframe data center.
Computing Resources: Amazon EC2
Elastic Compute Cloud (EC2) instances host the operating systems, mainframe emulation middleware, compiled application executables, and supporting software. Depending on workload characteristics, you may run batch COBOL workloads on dedicated instances separate from online transaction processing, or you may segregate instances by application domain. Instance sizing should be driven by the transaction and batch throughput data gathered during the Discover phase.
Storage: EBS, S3, and Glacier
Three AWS storage services collectively cover mainframe storage requirements:
- Elastic Block Storage (EBS) — block storage attached directly to EC2 instances; the primary storage layer for application data files.
- Simple Storage Service (S3) — object storage accessed via API; suited for bulk data repositories, data lakes for analytics, and large file archives.
- Amazon Glacier — low-cost archival storage for backup and long-term retention requirements.
Databases: Amazon RDS and Aurora
Amazon Relational Database Service (RDS) hosts migrated relational data. This includes DMS and DMSII data converted from ClearPath Libra systems, and RDMS data from Dorado systems, as well as any legacy flat-file data promoted to relational form during migration. RDS is available in several engines—Microsoft SQL Server, Oracle, PostgreSQL, MySQL, and MariaDB.
Amazon Aurora is worth evaluating as a migration target. It is MySQL-compatible (with a PostgreSQL-compatible variant also available) and is optimized for AWS infrastructure. Analyze your existing schema and access patterns to determine whether Aurora’s performance characteristics justify any additional migration effort.
Load Balancing: Amazon ELB
Elastic Load Balancing (ELB) distributes incoming application traffic across multiple EC2 instances. For high-volume online transaction workloads previously handled by mainframe front-end processors, ELB provides fault tolerance and ensures that no single instance becomes a bottleneck. Configure health checks so that unhealthy instances are automatically removed from the rotation.
Security: LDAP on EC2 and AWS IAM
Application-level security—user IDs, passwords, roles, and access permissions from the legacy environment—is typically migrated to an LDAP directory service hosted on a dedicated EC2 instance. Isolating the LDAP instance simplifies independent maintenance and patching.
AWS Identity and Access Management (IAM) handles infrastructure-level access control: which AWS users and roles can provision, modify, or decommission AWS resources. IAM operates at a different layer from application security and must be designed in parallel with the application security architecture.
A thorough analysis of the legacy security model is essential before finalizing the target security architecture. Mainframe security products often have fine-grained, program-level access controls that must be faithfully reproduced in the migrated environment.
Monitoring: Amazon CloudWatch
CloudWatch collects metrics, aggregates log files, triggers alarms, and can invoke automated remediation actions in response to resource state changes. It is the primary observability layer for migrated workloads, fulfilling a role analogous to mainframe operations consoles and job scheduling monitors. Third-party cloud-native monitoring tools can complement CloudWatch for application performance management (APM) and log analytics.
Source Control: AWS CodeCommit
AWS CodeCommit is a fully managed Git-based source control service. It replaces mainframe library management products (such as Harvest, SCLM, or vendor-specific change management tooling) and provides a foundation for modern CI/CD pipelines. Store migrated application source, newly developed source, compiled binaries, and configuration artifacts in CodeCommit repositories.
Is It Worth It?
Migrating a Unisys mainframe to AWS is not a trivial undertaking. It demands careful planning, experienced resources, and disciplined execution. But the outcome—mainframe business logic running on elastic, pay-for-use infrastructure—delivers lasting benefits:
- Cost model shift: Replace fixed mainframe licensing and hardware costs with variable, consumption-based AWS pricing.
- Talent pool: Open-systems and cloud skills are far more available than Unisys MCP or OS 2200 expertise, making hiring and knowledge transfer easier.
- Integration agility: AWS-hosted applications can integrate with REST APIs, mobile back-ends, data streaming services, and machine learning platforms that are impractical to connect to proprietary mainframe stacks.
- Operational resilience: Multi-AZ deployments, automated failover, and managed services reduce the operational burden compared to maintaining dedicated mainframe hardware.
- Preserved investment: A least-change methodology means 20–30 years of embedded business logic is carried forward, not discarded.
Organizations that delay mainframe modernization face compounding risk: shrinking talent pools, aging hardware, and increasing difficulty integrating with modern systems. For Unisys shops evaluating their options, a structured migration to AWS is a proven, viable path—not a leap into the unknown.