COBOL Support, Migration & Modernisation
the language is not the risk. The old compiler usually is.
For businesses running a COBOL application off the mainframe: Micro Focus, ACUCOBOL-GT or RM/COBOL on Windows, Unix or IBM i. We assess the programs and the data files, keep the system supported, move it to a current compiler where that is the better answer, and replace it in stages where it is not.
More about this service
We are an Australian team working remotely with businesses in the United States, the United Kingdom, New Zealand and Australia. Every engagement starts with a scoped technical assessment, so the estimate that follows is based on your code and your data.
- Assessment A scoped technical review before any estimate
- 18+ yrs Building business software
- Independent No licence commission, no reseller agenda
- US UK NZ AU Australian team, working remotely
Built here. Your data stays here.
- No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
- Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
- Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
The COBOL still works. The compiler and the people are the gap.
COBOL was built for exact business arithmetic and long batch runs, and it still does both well. That is why so many payroll, distribution, insurance and membership systems written in it decades ago are still in daily use. The programs were compiled once, the data sits in indexed files beside them, and the whole thing has run with very little attention since.
Read more
The obstacles are practical, not mysterious: a compiler and runtime several versions behind what the vendor now supports, a server that can no longer be replaced like for like, data that only the programs can read, and one or two people who know how the nightly run fits together. Each has a known answer, and rewriting everything is rarely the first one.
Our COBOL developer service is for businesses in Perth, Melbourne, Sydney and Brisbane. It covers three kinds of work: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.
Three ways forward for a COBOL application
In order of size. Many COBOL systems only ever need the first two.
-
Keep it and support it
The programs stay on the compiler and runtime they were built with. We set up a build environment that produces the same programs you run today, fix faults, make changes, and write down the batch runs and the file layouts. This suits a system that works and mainly needs to stop depending on one or two people.
-
Move it to a current compiler or platform
The same source is recompiled on a compiler its vendor still supports, such as Rocket Visual COBOL or a current ACUCOBOL-GT or RM/COBOL, often moving from an old Unix server to Linux or Windows at the same time. Staff keep the screens they know, and the business rules are not rewritten.
-
Replace it in stages
Where people need browser screens, live links to other systems or reporting the files cannot give, the data moves to a relational database and modules are rebuilt one at a time while the remaining COBOL keeps running beside them.
What we do with COBOL systems
Six kinds of work. Most engagements are two or three of them.
-
COBOL maintenance
Faults fixed and changes made in existing programs and copybooks, in the dialect they were written in.
-
Build recovery
A compiler, runtime and set of options that reproduce the programs you run today, written down so a build no longer depends on one machine.
-
Compiler and platform moves
Source recompiled on a supported compiler, or moved from AIX, HP-UX or Solaris to Linux or Windows, with results compared run for run.
-
Data file extraction
Indexed and sequential files read using their copybook layouts, including packed decimal fields and redefined records, and loaded into a database.
-
Batch runs and reports
Nightly and month end jobs, sorts, scripts and print files inventoried, documented and tested, because they are where the surprises are.
-
Staged replacement
Modules rebuilt as a web application one at a time, against data moved to SQL Server or PostgreSQL.
Supporting it, recompiling it and rebuilding it are different projects
Each trades cost against how much of the old system remains afterwards.
-
Stay on the current compiler
Lowest cost. The system is documented and supported, and changes can be made again. It stays tied to an old runtime, an old operating system and files that only COBOL programs can read.
-
Recompile on a supported compiler
Most of the code is reused and the business rules are not touched. The system ends up on maintained tools and current hardware. It is still COBOL, so the pool of people who can change it stays small, and the runtime licence continues.
-
Rebuild as a web application
Nothing depends on COBOL afterwards. It takes longest, and the risk is in rules that exist only in the code and in batch runs nobody wrote down. It is worth it when the business needs things the old design cannot give.
What a COBOL assessment looks at
COBOL the language is current. The risk is in the compiler version, the runtime licence and the data files. Mainframe COBOL on IBM z/OS is a different environment and is not the subject of this page. The product facts are from Rocket Software.
-
Which compiler and version
Micro Focus Net Express, Server Express or Visual COBOL, ACUCOBOL-GT, RM/COBOL, or IBM COBOL on IBM i. Each is its own dialect with its own extensions. Rocket Software has owned the Micro Focus products since May 2024 and released Visual COBOL 12.0 in 2026.
-
Net Express and Server Express
Rocket states that these are maintained only for existing customers and are no longer generally available, and names Visual COBOL as the successor. The Windows platforms on its Net Express 5.1 data sheet stop at Windows 7 and Windows Server 2008 R2.
-
Whether the source is complete
Programs (.cbl or .cob) and every copybook (.cpy) they include. A site that holds only compiled files, such as .int and .gnt files from Micro Focus or .acu files from ACUCOBOL-GT, can run the system but cannot change it.
-
Runtime and licences
Compiled COBOL needs its vendor runtime on every server, licensed separately from the compiler. We check what you hold and whether it can move to a new machine. Where licence cost is the driver, GnuCOBOL, a free compiler with compatibility modes for all three dialects, is an option to test.
-
The data files
Indexed, relative and sequential files, such as Micro Focus .dat and .idx pairs or ACUCOBOL-GT Vision files. The record layout is not in the file. It is in the copybooks, with packed decimal fields, redefined records and repeating groups that all need care.
-
Batch runs and reports
Shell scripts or batch files, sort steps, month end runs and reports written as print files. They are part of the application even though they are not in the COBOL, and they are mapped first.
-
Screens and integrations
Character screens over a terminal session, or ACUCOBOL-GT graphical screens through a thin client. Files left in folders for other systems, and tools such as AcuXDBC or Relativity that let other software read the data files with SQL.
-
Hardware and operating system
Often AIX, HP-UX or Solaris on a server that can no longer be bought, or an old Windows release. Programs built with 16-bit compilers do not run on 64-bit Windows at all.
A COBOL system that runs every day, and nobody left who can rebuild it?
What the assessment needs from you
A fixed-scope piece of work with a written result: the options, the risks of each, and a staged estimate. No production data is sent by email. We agree a secure way to share it first.
-
Compiler and version
The COBOL product and version the programs were built with, and the operating system they run on.
-
The source
Whether programs and copybooks exist for every module, where they are kept, and when they were last compiled.
-
Runtime licences
What runtime licences you hold, for how many users, and who supplied them.
-
The data files
The kinds of files in use, roughly how many and how large, and where they live.
-
Batch runs
What runs overnight and at month end, and who knows how.
-
Screens and users
How many people use it, and through which terminal emulator or client.
-
Integrations
Files in and out, printers and labels, and other systems that read the data.
-
What is hurting
The two or three problems that started the conversation: a server, a retirement, a report, a licence.
-
The way back
How long the business can run on the old system if a cutover has to be reversed.
From assessment to a supported system
Done remotely, with meeting times agreed to suit your time zone.
-
Technical assessment
We establish the compiler and version, what source and licences you hold, how the data files are laid out and what runs in batch. You get a written list of options with the risks of each and a staged estimate.
-
A working build
The programs are compiled from source on a machine kept for the purpose, and the output is compared with what you run today. Until that works, no change is safe.
-
Proof of concept
One representative piece, usually a few programs recompiled on a current compiler or one set of data files loaded into a database, is taken end to end on your data.
-
Staged work
The work is done in stages agreed from the assessment, each with its own scope and estimate, starting with whatever is hurting the business most.
-
Parallel runs and user testing
Old and new are run on the same data, and totals, record counts and report output are compared. Your staff test the work they do every day.
-
Cutover and support
Each switch is planned with a way back. We watch the first days of live use, then maintain the system for as long as it stays in service.
What people ask us about COBOL
Is COBOL still supported?
Yes. COBOL is a current international standard, last revised in 2023, and the main compilers are still developed. Rocket Software, which has owned the Micro Focus products since May 2024, released ACUCOBOL-GT extend 11 in 2025, and RM/COBOL 12.21 and Visual COBOL 12.0 in 2026. What is usually out of support is the old version a site is still running.
Do we have to get off COBOL?
Often not, and we will say so. COBOL that does its job is not a fault. The usual triggers are a server that cannot be replaced, a compiler too old for a current operating system, or nobody left who can make a change. All three can be fixed without a rewrite.
We run Net Express or Server Express. What are our options?
Rocket maintains both for existing customers only and names Visual COBOL as the successor. Recompiling there is the usual route, and it is a project with testing, not a reinstall. Compiler options, file handling and anything that calls the operating system all need checking.
Can our COBOL data be moved to a SQL database?
Yes. The files are read using the record layouts in the copybooks and loaded into SQL Server or PostgreSQL. The care goes into packed decimal fields, records that share one layout, dates stored as plain numbers, and reconciling totals afterwards.
Can COBOL be converted to another language automatically?
Tools exist that translate COBOL into Java or C#. The output runs, but it tends to read like COBOL written in another language, and somebody still has to maintain it. We treat conversion as one option to test on a sample of your programs, not as a promise.
Our COBOL programmer is retiring. What is urgent?
Two things. Get the batch runs, the month end steps and the file layouts written down while that person is still available. Then prove the system can be rebuilt from source on a second machine. Both are worth more than any technical change made this year.
Do you provide COBOL developers in Perth, Sydney, Melbourne and Brisbane?
Yes. We are an Australian team and we take on COBOL work for businesses in Perth, Sydney, Melbourne and Brisbane, and elsewhere in Australia. Most of the work is done remotely, by video call and screen share, with secure access to a copy of your system. The service is the same in every city: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.
How does this work from the United States, the United Kingdom or New Zealand?
Remotely. We are based in Australia and do not have offices elsewhere. Discovery is done by video call and screen share, with meeting times agreed to suit your time zone. Confidentiality, who can reach your systems and where your data is held are agreed in writing before work starts.
What does it cost?
The assessment is a fixed-scope piece of work with an agreed fee. The estimate for anything after it comes from what the assessment finds, in stages, so you are not asked to commit to a whole project on a guess.
Sending your details…
You can stay on this page while we send it.
Tell us about your COBOL system
What the system does, the COBOL compiler and version, whether you hold the source, and what is forcing the question. Include your country so we can suggest meeting times. Please do not send production data.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
Kasun Wijayamanna, founderYou deal with Kasun from scope to delivery. No account managers and no offshore handoff.