COBOL to Go Migration - A UK Enterprise Guide 2026

Go is a pragmatic COBOL migration target when simplicity, fast builds, and easy deployment matter more than a large enterprise framework ecosystem. It compiles to a single static binary with no runtime dependencies, it runs anywhere, and its built-in concurrency model is a natural fit for modernising COBOL batch processing into parallel workloads.

This guide explains what a COBOL to Go migration actually involves, the approaches available to UK enterprises, what it costs, and the one precision issue you must plan for up front.

TL;DR

• Go suits COBOL migrations that value simplicity, fast compilation, single-binary deployment, and easy concurrency over a heavy enterprise framework stack
• Go has no native decimal type: COBOL packed-decimal (COMP-3) fields default to float64, so financial calculations need a decimal library such as shopspring/decimal
• The three main approaches (automated conversion, parallel rewrite, and incremental "strangler fig" migration) carry different risk and cost profiles
• A mid-size migration typically costs £200,000 to £800,000 and takes one to two years; the decimal-precision decision and the data access layer are the critical planning items

Why Choose Go for a COBOL Migration

Go is not the biggest enterprise ecosystem, but it is a deliberate, focused language that fits certain COBOL modernisations very well:

Simplicity and readability. Go has a small, consistent feature set. Translated COBOL logic stays legible, and new team members become productive quickly, which lowers long-term maintenance risk.

Single-binary deployment. Go compiles to one self-contained executable with no runtime to install. For teams moving off a mainframe and onto Linux servers or containers, deployment becomes trivial.

Built-in concurrency. Goroutines and channels make it straightforward to parallelise the sequential, record-by-record batch processing that dominates COBOL systems. A nightly batch job that ran serially on the mainframe can often be restructured to process partitions concurrently.

Fast compilation and cloud-native fit. Go's fast builds and small container images suit modern CI/CD and cloud deployment on Azure, AWS, or GCP.

The Decimal Precision Decision You Must Make Early

This is the most important planning point for a COBOL to Go migration. COBOL PIC 9 and COMP-3 fields hold exact base-10 decimal values, which is what financial systems depend on. Go has no native decimal type. The default mapping for a decimal field is float64, which uses IEEE 754 binary floating point and can introduce rounding errors in monetary calculations.

For any financial or decimal-sensitive logic, the correct approach is to use a decimal package such as shopspring/decimal in place of float64. A good converter makes this decision visible rather than silent: the Mecanik COBOL to Go migration tool maps decimal fields to float64 by default but flags every one of them in its Migration Report, so you can decide field by field where exact decimal arithmetic is required. Never ship money code on float64 without that review. If exact decimal precision without any extra library is a priority, C# (native decimal) or Java (BigDecimal) may be a better fit.

The COBOL Constructs That Need Real Translation

A safe migration translates COBOL semantics into idiomatic Go, not text:

• Group items (level 01-49 hierarchies) become Go struct types with exported, PascalCase fields (ACCOUNT-BALANCE becomes AccountBalance).
• PIC clauses map to the right Go type: string for alphanumeric, int16 / int32 / int64 for numeric by digit count, and float64 (or a decimal package) for decimal fields.
• PERFORM ranges become function calls; paragraphs and sections decompose into functions.
• EVALUATE / WHEN maps to switch statements.
• COPY and REPLACE (copybooks) must be resolved, including nested copybooks.
• EXEC SQL (DB2), EXEC CICS, and VSAM need redesign onto Go's database/sql, sqlx, or an ORM such as GORM, and modern service patterns.
• EBCDIC encoding and fixed-width layouts need explicit conversion to Unicode and typed models, typically with buffered (bufio) I/O.

Migration Approaches

There are three main approaches, each with a different risk and cost profile.

1. Automated Conversion

Tooling parses COBOL and generates Go with package structure, typed structs, sized integers, and buffered file I/O. It removes the mechanical work quickly. It does not make the architectural decisions for you.

Best for: Large codebases where the priority is eliminating COBOL dependency quickly.

Risk: Decimal fields, embedded SQL, CICS interactions, and dynamic calls all need human review. The Migration Report exists precisely to surface these.

2. Parallel Rewrite

The Go system runs alongside the COBOL system, both processing the same inputs, with outputs validated against each other until Go passes and COBOL is decommissioned.

Best for: Mission-critical systems where continuity cannot be risked.

Risk: Running two systems in parallel doubles operational cost during the migration and demands disciplined reconciliation.

3. Incremental Migration (Strangler Fig)

COBOL programs are replaced with Go equivalents one at a time. The system becomes a hybrid, then eventually pure Go.

Best for: Large monolithic COBOL systems where a full rewrite is impractical.

Risk: The hybrid state can persist longer than planned and demands careful interface design.

For most UK migrations, the strangler fig approach combined with selective automated conversion delivers the best balance of risk and velocity.

COBOL to Go Migration Costs in the UK

Cost depends heavily on codebase size, complexity, and approach. Indicative ranges for UK enterprise projects:

These figures cover analysis, migration, testing, and go-live support. They exclude ongoing operational costs, training, and downstream integration work that often surfaces mid-project.

The Mecanik COBOL to Go migration service specialises in UK enterprise migrations, covering assessment, conversion, data access layer implementation, and output parity testing. For organisations weighing target languages, the COBOL migration overview sets out the full range including C#, Java, Python, C++, and Rust. For migrations off IBM z/OS, the legacy mainframe migration service covers the infrastructure decommission alongside the code migration.

Key Risks and How to Manage Them

Decimal precision. The defining risk of a Go migration. Review every float64-mapped field flagged in the Migration Report and switch financial fields to a decimal package before go-live.

Undocumented business logic. Decades of embedded business rules with no external documentation. Discovery and documentation is the most time-consuming, risk-intensive part of any migration.

The data access layer. EXEC SQL against DB2 and VSAM handling must be redesigned onto database/sql or an ORM. This is often the largest single work item.

Performance and concurrency. Go performs well and its concurrency can outperform a serial COBOL batch, but restructuring sequential logic into parallel workloads must preserve ordering and correctness guarantees.

Regression testing coverage. Prove the Go output matches the COBOL with comprehensive regression testing on real (anonymised) data, paying special attention to decimal-sensitive calculations. Build the suite before migration begins.

Cut-over risk. A detailed cut-over plan with rollback and reconciliation is mandatory.

Key Takeaways

• Go suits COBOL migrations that prioritise simplicity, single-binary deployment, and concurrency.
• Go has no native decimal type; plan the float64 versus decimal-library decision for every financial field up front.
• Most UK enterprise projects use the strangler fig approach with selective automation.
• The biggest risks are decimal precision, undocumented business logic, and the data access layer.

Related reading: COBOL to C# Migration - A UK Enterprise Guide 2026, COBOL to Python Migration - A UK Enterprise Guide 2026, COBOL to Java Migration - A UK Enterprise Guide 2026 and COBOL Migration Cost, Timeline and Risk - A UK Guide 2026.

Frequently Asked Questions (FAQ)

Why choose Go over Java or C# for COBOL migration?
Choose Go for simplicity, fast compilation, single-binary deployment, and built-in concurrency for parallelising batch work. Choose Java or C# when you need a larger enterprise framework ecosystem or native/library decimal support with less manual review.

How does Go handle COBOL packed-decimal fields?
Go has no native decimal type, so decimal fields default to float64, which can introduce rounding for financial calculations. A good converter flags every decimal field so you can replace float64 with a package such as shopspring/decimal where exact arithmetic is required.

Can COBOL logic be automatically converted to Go?
Yes, with tooling. A good converter produces package-based Go with typed structs, sized integers, and buffered I/O, and flags embedded SQL, CICS interactions, dynamic calls, and decimal-precision fields for manual work. Architectural decisions remain human tasks.

What happens to COBOL data formats like COMP-3 and EBCDIC?
COMP-3 maps to float64 by default (review for exact-decimal needs). EBCDIC text and fixed-width layouts require explicit conversion to Unicode and typed models, tested against real data before production use.

How long does a COBOL to Go migration take?
Small, well-documented systems take three to nine months. Medium enterprise systems run twelve to twenty-four months. Large mainframe programmes can take three to five years for full decommission.