Public Debt Management Office, Ministry of Finance
฿9B+in contract value managed on the system we built
One open-source system for Thailand’s public debt, for the PDMO
- Enterprise Software Development
- Application Modernization
- Data Migration
Maintenance & Modernization
Application Modernization
We work out what is wrong with the system you have, decide part by part whether to rehost, replatform, refactor or leave it alone, and make the changes in stages while daily work continues.
Application modernisation means reworking an ageing system so it can be changed safely and connected to other systems again. Usually a clean interface goes in front of the old system and its parts are replaced behind it one at a time.
We were part of the delivery team for the Public Debt Management System at Thailand's PDMO, which replaced the office's SAP-based GFMIS-TR with seven modules that post to the government's New GFMIS Thai.
Is this the right fit?
The situations this work is built for, and what you get at the end of it.
You may need this if
Nobody dares change the system
The people who built it have left, there are no tests, and any change might break something.
The platform is out of support
The operating system, database or framework no longer receives security patches, and upgrading one part breaks another.
New work waits on the system
New products and regulatory changes wait months because few people understand the system well enough to change it.
An earlier rewrite failed
An attempt to replace everything at once used up the budget.
What we deliver
Modernisation assessment
What is wrong, what each option costs, including doing nothing, and which parts justify the work.
An API over the old core
An interface that lets other systems and new channels connect without changes to the old code.
One capability at a time
Each part moves behind the interface; the old version runs until its replacement is proven.
Tests for code nobody understands
Characterisation tests that record what the system does today, so breaking changes are caught before release.
Data migration and reconciliation
Data moved into the new components, with counts and totals reconciled against the source.
How we work
Every engagement runs through the same six-stage fitting process, from the first consultation to long-term care. The stages stay in the same order; how deep each one goes depends on the project.
See the full fitting process- ConsultationDiscover
- MeasureAnalyze and architect
- PatternDesign
- FittingBuild with you
- FinishingHarden and launch
- AftercareMaintain and support
Deciding between a rewrite and a staged replacement
We first establish what the complaint is, because each common complaint has a different remedy. A system that is slow to change usually needs tests and some restructuring. One that cannot connect may only need an API in front of it. If nobody understands it, documentation comes first. If it runs correctly, costs little and only looks dated, we recommend leaving it alone.
When parts do need replacing, we usually work in stages, moving one capability at a time behind a new interface. This has two costs to plan for. For a while you run and reconcile two systems side by side, and benefit arrives unevenly: a programme more than half finished may deliver little until the most-used capabilities have moved. We order the work so those move early. A full rewrite makes sense when the business process has changed so much that the old system's rules no longer apply.
Organizations we work with
Engagements span build, integration and long-term support. Named with permission; clients under NDA are not listed.
Related services
- System Integration & API Development: when connecting the system is the only problem.
- Enterprise Software Development: when you have chosen a new system built from scratch.
- Cloud Migration & Architecture: when the system is also moving to the cloud.
- Data Migration: when moving the data is the main work.
Frequently asked questions
How much does application modernisation cost?
It depends on the size of the system, the state of its code and data, and how many parts need replacing. We start with an assessment, estimated in writing after a short scoping call, and estimate later stages once it is done. Public-sector work is priced against the TOR.
Should we rewrite the system or modernise it in stages?
Usually in stages. A full rewrite puts all the risk on one cutover, often freezes new features until it catches up, and tends to lose business rules nobody wrote down. The assessment shows which parts, if any, justify rebuilding from scratch.
Can you work on an undocumented system you did not build?
Yes, and most of this work is like that. We read the code, database and deployment setup, and talk to the people who operate the system. The first weeks are slower while we build context, and we include them in the estimate. We document what we find as we go.
How do you avoid breaking things nobody understands?
Before changing a part, we write characterisation tests that record what it does today, including behaviour nobody intended. A change that alters that behaviour then fails a test before release. Where current behaviour turns out to be wrong, the business decides whether to keep it.
How do you keep the business running during modernisation?
The old system stays in service for each capability until the replacement has run on real work and the results reconcile. Each stage has a rollback plan. If an outage window is needed, we agree it with you in advance and rehearse the cutover first.
Related work
GMM Grammy
30+ accounting reports on demand for GMM Grammy
- Enterprise Software Development
- Data & Analytics
- UX/UI Design & User Research
Next step
Start with a conversation
Tell us about the problem you are trying to solve. A senior person reads every inquiry and replies with our view of fit, scope and cost, including when another option would suit you better.