Legacy system modernisation and mainframe to AWS cloud migration
Legacy system modernisation renews ageing software without losing the business rules inside it. Arke Technologies, in Johannesburg, assesses, migrates and integrates legacy systems for South African organisations, public bodies and schools: databases and applications move to AWS, Azure or private cloud, and programmes such as a mainframe to AWS cloud migration are planned in stages.
What counts as a legacy system
A legacy system is software your organisation relies on that has become hard to change, support or secure. Age alone does not make a system legacy; risk does. It takes many forms: a Microsoft Access database that runs payroll adjustments, a desktop application on an unsupported framework, an on-premises accounting or billing system several versions behind, a web application only one former employee understands, or, in banks, insurers and large public bodies, a mainframe running COBOL batch jobs.
The warning signs are consistent:
- The operating system or database is out of vendor support. See Windows Server upgrades.
- Nobody can change it safely, so changes stop and workarounds multiply in spreadsheets.
- It has no API, so every other system gets its data by export and re-keying.
- Auditors raise findings on access, logging or backups that the system cannot resolve.
- It cannot meet POPIA requirements for access control, retention or deletion.
Mainframe to AWS cloud migration and Azure mainframe migration
Mainframe to cloud migration moves a mainframe's programs, data and batch processing onto cloud infrastructure, usually AWS or Microsoft Azure. There are four routes, and large estates use more than one:
- Rehost on an emulation layer, with the code largely unchanged, running on cloud servers.
- Refactor COBOL and similar code into a modern language with conversion tooling, then clean it up.
- Rewrite the business rules as new services, one business domain at a time.
- Replace the function with a packaged product or SaaS.
AWS mainframe migration and Azure mainframe migration both come with published reference architectures and tooling for rehosting and refactoring, and Google Cloud offers similar paths. The right cloud depends more on your existing estate, licensing and skills than on the mainframe itself. See our AWS and Microsoft Azure services.
In migrating mainframe to cloud, we handle assessment and inventory, the target architecture and landing zone, data migration and reconciliation, the integrations downstream systems depend on, and testing and cutover. Whether the target is AWS or Azure, mainframe application migration is best planned as a sequence of releases, one workload and its interfaces at a time, not a single weekend cutover.
Mainframe to cloud migration challenges
Undocumented business rules. Decades of logic live in code and in the heads of a few people. We extract the rules and confirm them with the business before anything moves.- Data conversion. Mainframe data uses EBCDIC encoding, packed-decimal numbers and fixed-width records. Every field is converted and reconciled, to the cent where money is involved.
- Batch windows. Overnight job chains with strict dependencies must run in the same order, within the same window, on the new platform.
- Performance. Transaction volumes the mainframe handles comfortably are load-tested on the target before cutover.
- Interfaces. Many downstream systems read files the mainframe produces. Each interface is listed, rebuilt or preserved, and tested.
- Skills. Mainframe and COBOL skills are scarce, so knowledge transfer is planned from the first week.
- Mainframe disaster recovery. A mainframe often has mature, well-rehearsed recovery. The cloud target must meet or beat the same recovery time and recovery point objectives, across availability zones, with restores tested before go-live. See backup and disaster recovery.
Legacy data migration
Data migration from legacy systems is where most modernisation risk sits. A legacy system data migration moves records that have been edited, patched and duplicated for years, often under rules no one remembers. We run legacy data migration as its own workstream: profile the data, agree cleansing rules with its owners, migrate in rehearsals, and produce a reconciliation report (record counts, balances and exceptions) that the data owner signs before cutover. Every run has a rollback plan.
POPIA shapes the work. Minimisation means you migrate the personal information you still need, not everything the old system ever held; the rest is archived or destroyed under your retention schedule. See data migration.
Legacy system integration and mainframe integration
Sometimes the right first step is not migration. Legacy system integration puts a modern interface in front of the old system (an API, an event feed or a controlled file exchange) so new applications, reporting and portals can use its data while the core stays put. Mainframe integration works the same way, exposing transactions and records to modern systems without rewriting them.
Integration buys time, removes re-keying and makes a later legacy system migration smaller, because the new interfaces already exist when the core is replaced. See systems integration and ERP and accounting integration. If the replacement is new software rather than a package, it is part of our custom software development practice: SaaS product development, web application development or mobile app development, with every release tested under our DevOps and quality engineering discipline.
What legacy modernisation costs
The cost of a legacy migration is set by the estate, not by a rate card. The main drivers:
- Size: the number of applications, interfaces and batch jobs.
- Knowledge: how well the current system is documented, and whether its original developers are still available.
- Data: volume, quality and how many years of history must move.
- Approach: rehosting costs a fraction of a rewrite, but delivers fewer benefits.
- Assurance: testing and parallel-run effort, heaviest for financial and billing systems.
- Running costs: the target platform's hosting and licences, which we model before you commit.
Published South African rates for IT project work run from about R550 to R750 an hour ex VAT (matnet.co.za, September 2026); the estate decides how many hours. We start with a discovery and assessment, quoted per project. It produces the roadmap, the business case and a quote for each later phase, so nothing larger is committed until you have seen the evidence.
Last reviewed: September 2026.
Governance, compliance, procurement and continuity
- Governance and reporting. A named lead, a programme plan with phase gates, a risk and issue register, change control, progress reporting at a cadence agreed in the proposal, and go/no-go criteria agreed before every cutover. Once live, support runs under an SLA with a monthly service review.
- Compliance. POPIA security safeguards and minimisation, with an operator agreement under section 21 where we process personal information for you. We work to ISO/IEC 27001-aligned controls, support King IV Principle 12 reporting to boards, and keep the audit trail PFMA and MFMA reporting expects.
- Procurement. Level 1 B-BBEE contributor (sworn affidavit available on request), which gives buyers 135% procurement recognition. Company documents, CSD supplier number and tax compliance status are available on request, and we complete SBD forms when a bid requires them. See company facts.
- Continuity. You own your data, credentials and documentation, and migrated systems run in cloud accounts registered to your organisation. We document the new system, hand over runbooks and train your team, so you do not swap one person-dependency for another.