Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

COBOL can be replaced by Rust, but a rewrite is only one possible route—and the available evidence does not establish a verified direct converter or a UK production case study for COBOL-to-Rust. Before committing, compare a Rust pilot with retaining, encapsulating, replatforming or selectively refactoring the existing system. Decide against measurable business and operational criteria, not the appeal of a new language.

What does COBOL migration refer to?

“Migration” can describe three different kinds of change: moving a COBOL application to another hosting platform, modernising how it connects to other systems, or replacing its implementation language. These changes have different risks and do not necessarily happen together. A platform move can preserve COBOL semantics; an API can make a capability easier to use without changing its implementation; a Rust rewrite changes the implementation and must reproduce the required behaviour.

IBM, a vendor, notes that COBOL modernisation involves more than translating code: it can include application integration, data architecture, runtime replacement, transaction integrity and security. Its guidance identifies encapsulation, DevOps practices, migration and refactoring as distinct approaches. IBM’s COBOL modernisation overview was published on 27 November 2025 and updated on 6 April 2026.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Can a UK enterprise rewrite COBOL in Rust?

Yes, as an engineering choice, but the available evidence does not establish a verified direct COBOL-to-Rust conversion product, a named UK production case study, or Rust-specific UK mainframe service capability. Nor does it establish comparable costs, performance results or defect rates for such migrations. Treat Rust as a candidate target whose fit must be demonstrated for your own application, not as a proven default.

Translation alone cannot demonstrate equivalence. The team must discover the application’s actual business rules and check such behaviours as numeric precision and rounding, date handling, character encoding, file layouts, transaction boundaries and error handling. These are areas to investigate in the estate being migrated, not claims that a particular COBOL system has defects.

Rust’s official online learning resource is The Rust Programming Language. It teaches Rust generally; it is not a COBOL migration method or a substitute for application-specific verification.

Which modernisation path fits the system?

Compare the paths against the same acceptance criteria: business outcomes, data-conversion correctness, transaction and batch behaviour, performance under peak and failure conditions, security, observability, recovery objectives, operator capability and rollback. Set thresholds before implementation. The criteria below are evaluation prompts, not a universal checklist prescribed by a source.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Path What changes Questions to resolve
Retain and improve COBOL Improve tests, documentation, tooling, deployment or compiler/runtime versions while retaining the language. What is the support horizon? Are skills, dependencies and runtime constraints manageable? Can the system be tested and changed reliably?
Encapsulate existing functions Keep COBOL business logic, but expose selected capabilities through interfaces or APIs. Are boundaries and data ownership clear? What latency and integration complexity will the interface add? How will changes be rolled back?
Replatform COBOL Move workloads or runtime while retaining COBOL semantics. Will programs, data access and transaction behaviour remain compatible? How will performance, operating costs, vendor dependence and operational responsibilities change?
Refactor or rewrite selected components in Rust Replace a bounded capability, expanding only after equivalence and operational readiness are demonstrated. Can the team reproduce numeric, date and file behaviour, transaction boundaries, security and observability? What are the performance and lifecycle-cost trade-offs?
Replace the application Replace the application, potentially including its data and integration structures. Can migration be sequenced without disrupting service? How will data be reconciled, fallback handled, regulatory evidence retained and the new system maintained?

A UK Digital Marketplace listing for AWS Mainframe Modernization describes COBOL/PL/I analysis, refactoring or replatforming to a managed runtime, automated testing and data replication. It is an example of a broader modernisation service category, not evidence of a Rust conversion product. See the marketplace listing.

How should a migration programme proceed?

IBM advises planning and evaluation, starting small, scaling gradually, testing and documenting. The following sequence applies those principles to a COBOL-to-Rust decision; it is a practical approach, not a mandated method.

  1. Inventory the system and assign ownership. Map programs, copybooks, scheduled jobs, transaction flows, databases and files, external interfaces, controls and runbooks. Identify a business owner for each capability and record dependencies and unknowns.
  2. Recover the behaviour that must be preserved. Gather user and operator knowledge, business rules, production traces, reports, reconciliation controls and existing tests. Treat undocumented behaviour as a discovery risk rather than assuming the code alone explains the system.
  3. Select a bounded pilot. Choose a component with defined inputs and outputs, limited dependencies and a credible way to compare results. Avoid beginning with the most critical, tightly coupled path simply because it is prominent.
  4. Measure a representative baseline. Record current throughput, latency, failure and recovery behaviour, transaction consistency, operating cost and change lead time on representative workloads. No COBOL-versus-Rust benchmark is established by the sources cited here.
  5. Define the target boundary. Decide whether Rust will own a service, batch step or domain capability. Specify data ownership, interfaces, error semantics and idempotency, as well as how the new component will work with the remaining COBOL and platform estate.
  6. Port incrementally with a tested fallback. Where feasible, run old and new paths in parallel or shadow mode, reconcile their outputs, and practise rollback. A language change by itself does not remove platform or integration dependencies.
  7. Test business behaviour and operations. Use characterisation or golden-master comparisons where they are valid. Include edge cases, numeric precision and rounding, character encodings, dates, file layouts, transaction boundaries, security, load, recovery and deployment.
  8. Expand only when the evidence meets the agreed criteria. Include training and ongoing support in the decision. A pilot may justify extending Rust, choosing another modernisation path or retaining COBOL.

What should UK public-sector teams assess?

The Technology Code of Practice (TCoP) is a cross-government standard used in the Cabinet Office spend-control process. It says, “You should use the TCoP for all of your technology projects or programmes.” Public-sector teams should consider every point during spend control and explain to GDS Assurance where legacy technology limits compliance. Its considerations include open source, open standards, cloud-first options, security, privacy, integration, data, purchasing strategy and sustainability. Read the Technology Code of Practice.

The TCoP’s stated scope does not make it a statutory obligation for every UK business. Private-sector organisations can use its topics as governance prompts without treating them as a legal requirement.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

GDS and the Central Digital and Data Office (CDDO) recommend documenting existing systems, designing interoperable data, using common authentication, producing data using open standards, documenting APIs and using OpenAPI to document REST APIs. They also recommend reuse where a suitable existing service is available. Their reference architecture does not replace spend controls or service assessment. Read the data and APIs reference architecture, published 22 March 2021.

For a migration, apply those principles to the interfaces between Rust, remaining COBOL components, data stores and suppliers. Choosing Rust does not by itself guarantee open standards, interoperability or freedom from supplier lock-in.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What do UK government legacy figures say about COBOL?

A Government Digital Service blog post published on 7 July 2026 reported that approximately 60% of government digital services had migrated to cloud and around 28% of the government estate remained legacy. Those figures describe general government digital-service and estate status; they do not measure COBOL prevalence or progress on COBOL-to-Rust projects. The post also described the UK cloud market as worth over £10.5 billion in 2024 and growing at 30% each year, which is cloud-market context rather than a measure of COBOL or Rust activity. Read the GDS post.

The sources cited here do not establish an authoritative UK COBOL line count, migration rate, cost-saving estimate, delivery-time estimate or defect-rate comparison. Do not use broad legacy or cloud statistics as a proxy for any of those measures.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How should teams evaluate a procurement offer?

Check whether an offer covers the actual work required: assessment, code analysis, refactoring or replatforming, testing, data replication, integration and operational handover. Confirm the live framework, service terms, constraints, region, support, pricing and suitability directly during procurement; marketplace listings and their terms can change. The cited marketplace example describes COBOL/PL/I modernisation capabilities, not direct translation into Rust.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.