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
Data Migration
We move data out of legacy systems and check that the destination matches the source. The work covers profiling the source, mapping and cleansing, agreed reconciliation checks, and a rehearsed cutover with a tested rollback.
Data migration means moving data from an old system into a new one and proving it arrived complete and correct. Most of the effort goes into understanding the source data and checking the result.
On the Public Debt Management System for Thailand's PDMO, our work included migrating data from the SAP-based system it replaced. For a major Thai music company, we designed the migration of its catalogue into a new CMS.
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
A new system has to go live
A replacement is being built or bought, and years of records must move across before go-live.
Nobody trusts the source data
The old system has duplicates, mixed date formats and structured information typed into notes fields.
Several systems are merging into one
Customer, product or financial records live in more than one system, and the copies disagree.
The cutover date cannot move
Go-live is tied to a contract end, a licence expiry or a new fiscal year.
What we deliver
Source data profiling
What the source holds: volumes, duplicates, repurposed fields, retired codes and records that will not map cleanly.
Mapping and cleansing rules
Written, tested rules the business can review, with each cleansing decision recorded.
Reconciliation checks
Record counts, financial totals and sample comparisons, agreed before anything moves, showing whether source and destination match.
Exception handling
A path for records that cannot move as they are: fixed first, migrated with a flag, or archived.
Rehearsed cutover and rollback
Trial runs on production-sized data, with timings measured and the rollback carried out before the real cutover.
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
What we agree before any data moves
In a system that has run for years, fields get reused, status codes are retired but stay on old records, and staff type structured information into free-text fields. None of this shows in the schema, so we profile the data before estimating the migration in detail.
Before the first trial run, we agree the following points with you in writing:
- the reconciliation rule: which counts and totals must match, and what tolerance is acceptable;
- the exception path: what happens to records that will not map cleanly, and who decides;
- the cutover plan: how long the window is, who signs off, and the point at which we roll back.
We then rehearse the cutover on production-sized data, measure each step and carry out the rollback at least once, so the real cutover repeats steps the team has already run.
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 data must move between systems continuously.
- Enterprise Software Development: when the destination system has not been built yet.
- Application Modernization: when the old system is being replaced in stages.
- Data & Analytics: when data is combined for reporting and the sources stay in use.
Frequently asked questions
How much does a data migration cost?
The main drivers are the number of source systems, data volume and quality, how many exceptions need a business decision, and the cutover window. We give a written estimate after a short scoping call, often pricing profiling as a first step. Public-sector projects are priced against the TOR.
How long does a data migration take?
It depends on the number of source systems, the quality of the data and how quickly the business can decide on exceptions. Most of the time goes on profiling, mapping and reconciliation, and the transfer itself is a small part. We set the timeline once the source is profiled.
What if our data quality is poor?
That is the usual situation. For each problem, your data owners decide whether to fix the records first, migrate them with a flag, or leave them in an archive, and we record the decision. Cleaning everything is seldom necessary and usually costs more than it returns.
Can you migrate data without downtime?
Sometimes, by running both systems in parallel and moving data in stages. It costs more and makes reconciliation harder, because the data keeps changing during the move. For internal systems, a planned outage over a weekend or public holiday is often cheaper and safer.
How do you protect personal data under the PDPA during migration?
Extracts, staging databases and test copies all add places where personal data sits. We move only the fields the new system needs, encrypt staging copies, use masked data for testing where possible, and delete each intermediate copy once the migration is signed off.
Related work
Media & Entertainment (name withheld under NDA)
From catalogue to streaming platforms: designing a music CMS
- UX/UI Design & User Research
- Solution Architecture
- Data Migration
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.