Legacy systems, modernised in steps
Legacy systems and mainframes still run core operations for many large organisations. Licence fees, a shrinking pool of COBOL and PL/I specialists, and slow release cycles make them expensive to keep. We break these systems into event driven services on Google Cloud (Cloud Run, GKE and Eventarc) without stopping the business that depends on them.
The strangler fig approach
Instead of a big bang rewrite, we replace the old system one piece at a time:
- Route at the edge: Put Google Cloud Load Balancing or Apigee, with Cloud Armor, in front of the legacy platform so traffic can go to either old or new services.
- Extract features: Move one business domain at a time (for example identity, billing or inventory) into its own service on Cloud Run.
- Keep data in sync: Stream transactions between legacy databases (such as DB2 or Oracle) and Cloud Spanner or Cloud SQL using change data capture with Datastream or Debezium and Pub/Sub.
- Decommission: Send traffic to the new services and switch off legacy components as each is fully replaced.
What we do
Mainframe refactoring and code translation
- Code analysis: Gemini assisted static analysis of COBOL, RPG and CICS logic to surface undocumented business rules.
- Translation: Rewrite procedural code as maintainable, type safe Go, Java or Python services.
- Side by side testing: Automated regression tests that compare legacy and new outputs for the same inputs.
Database modernisation
- Relational migration: Move DB2, Oracle and SQL Server databases to Cloud Spanner (for globally consistent transactions) or Cloud SQL for PostgreSQL.
- Live replication: Continuous replication with Datastream and Dataflow to keep cutover downtime to a minimum.
Where the new services run
- Cloud Run: Managed serverless containers that scale to zero when idle, so you stop paying for idle capacity.
- Google Kubernetes Engine (GKE): For complex stateful workloads, high compute needs and hybrid connectivity.
Compliance and security
Modernisation in banking, insurance, healthcare and government has to meet regulatory frameworks:
- APRA CPS 234 and CPS 230: Operational resilience and information security controls built into the Terraform modules.
- SOC 2 Type II and ISO 27001 alignment: Drift detection, immutable audit logging in Cloud Logging and central secret management in Secret Manager.
- Zero trust security: Identity Aware Proxy (IAP), mutual TLS with a service mesh, and Cloud Armor DDoS and WAF protection.
Related
- Mainframe migration to Google Cloud: AI specification extraction and Google Cloud Dual Run for IBM z/OS and IBM i (AS/400) workloads.
- AIX to Google Cloud migration: recompile Big-Endian C/C++ and Java off IBM Power to Linux, or run AIX on IBM Power for Google Cloud (IP4G).
- Apigee API management: the routing layer we use in front of legacy systems during a strangler fig migration.
- Agentic engineering: using AI agents to analyse and refactor legacy codebases.
Questions we get asked
Why use the strangler fig pattern instead of a full rewrite?
Big bang rewrites tie up engineering capacity for years and carry high cutover risk. The strangler fig pattern places an API routing layer in front of your legacy monolith or mainframe and moves one business domain at a time onto Cloud Run or GKE, while the existing system keeps running.
Should we modernise onto Cloud Run or Google Kubernetes Engine (GKE)?
We default to Cloud Run for stateless HTTP APIs, event driven workers and teams that want no cluster management. We recommend GKE Autopilot when workloads need custom network meshes, stateful daemonsets, or GPU and TPU scheduling.
How do you keep legacy databases and new cloud services in sync during migration?
We build change data capture (CDC) pipelines with Datastream and Pub/Sub, behind an anti corruption layer, so legacy and cloud services work on consistent data until the legacy database is retired.
Talk to an architect who has done this before.
Bring your current setup and the outcome you need. You will get a view on the approach, the risks and roughly what it costs.
Straight to a senior GCP architect. No SDR, no slide deck.
Not ready to talk? See how we migrated Hapana off AWS →
Or call +61 2 8359 9507 · Hello@aviato.consulting