Connecting to Legacy Government Systems: Formats and Security Reviews

Picture a hypothetical project team that has planned two weeks in the schedule to connect a new system to a government agency's decade-old registry database. The person who originally built that old system has already left. The only API documentation left behind is a single-page Word file last updated four years earlier. In a situation like this, connecting the two systems can take more than two months, because the team has to reverse-engineer each field from sample data, then wait in a separate queue for a security review before being granted access to the production environment.

This is not an unusual scenario. Connecting a new system to an old one inside a government agency or a large enterprise often carries hidden costs like these. This is not a question of when to rewrite or refactor the old system — that is a separate decision with its own trade-offs. It is a practical question every project has to answer regardless of that decision: how do you connect two systems so the data is correct, the connection is secure, and the delivery date does not slip by a margin nobody planned for?

The new system in question might be a citizen-facing e-service, an agency's own back-office system, or a vendor's system that needs to pull records from a government database. Whichever it is, the same mechanics apply: understand how the old system actually stores its data, choose an exchange method that matches the risk and the speed the work needs, and get sign-off from whoever owns security on the old system's side before any real connection happens.

What field mismatches actually look like in practice

Many legacy systems inside government agencies have no formal API documentation at all. What exists instead is knowledge inside the head of whoever used to maintain it, or a document written at project kickoff years ago that was never updated as the code changed. The practical result is field mismatches: the old system might store a national ID as a string with dashes, while the new system expects digits only. A status code might run 1 through 5 with no surviving explanation of what each number means, forcing the team to guess from sample records and then track down someone who still remembers.

Character encoding causes just as much trouble. Some older government systems still store Thai text in TIS-620 rather than UTF-8, which is what most new systems assume by default. Skip the conversion step and Thai names come out as garbled characters. Date formats are another common trap: the old system might store the Buddhist calendar year in two or four digits, while the new system expects the Gregorian year in ISO 8601 format. Get this wrong and birthdates or approval dates end up decades or even centuries off, often unnoticed until someone files a complaint.

Null handling is a quieter risk. Some old systems use "0" or "-" as a stand-in for missing data instead of a true null value. If the new system reads that "0" as an actual number, every summary report downstream is wrong, with no error message anywhere to reveal it.

Nothing crashes. The numbers are just silently wrong.

The work that never shows up in a project plan is the time spent understanding the old system, not the time spent writing the integration code itself. Those are two different kinds of work, and estimating them as a single number tends to undercount the first one. It is worth separating the two explicitly when estimating, and giving the understanding phase its own buffer, since it is far harder to control than writing code.

Batch files vs. real-time APIs: what each one costs you

When the old system has no ready API, the fallback is usually a batch file exchange — a CSV or fixed-width file transferred over SFTP on an agreed schedule. This is faster to build, easier to test, and does not require opening a live channel into a system that was never designed to handle continuous load. The trade-off is that the data is never current: if a transaction needs an immediate status update, such as an approval a user is waiting for on screen, batch exchange cannot deliver that. It also needs a reconciliation step — checking that every file sent actually arrived intact at the other end — because files go missing, get sent twice, or change shape without warning.

A real-time API gives you current data, but it needs someone on the old system's side willing to expose a new endpoint, tighter authentication and access controls, and it usually goes through a stricter security review than batch does — because it is a channel that stays open, not a file transfer that closes the moment it finishes. Some agencies may also require this kind of connection to run over a dedicated network, such as MPLS or a point-to-point VPN, rather than the public internet, which adds a procurement and budget-approval step most development teams do not anticipate. Choosing between the two is not purely a technical decision; it is a trade-off between how current the data needs to be and how quickly the connection can get approved.

The data-exchange standards a government agency will hold you to

Thailand's Digital Government Development Agency (DGA) maintains a framework called TGIX (Thailand Government Information Exchange) for how agencies connect and exchange data with one another. The framework splits into two parts: Linkage Standards, covering the connection architecture and channels, and Semantic Standards, covering the definitions and structure of the data being exchanged (source: DGA, accessed 2026-09-29). Under the Digitalization of Public Administration and Services Delivery Act B.E. 2562 (2019), government agencies are also required to connect and exchange the digital data they produce and hold when another agency requests it (Section 13). Ask early in the project whether it needs to reference TGIX at all — if it does, the data structure has to follow DGA's own definitions rather than whatever is most convenient for the new system alone.

Many agencies route this exchange through a central hub called GDX (Government Data Exchange), which acts as a gateway between the requesting system and the data owner's system without storing the data itself (source: DGA GDX, accessed 2026-09-29). If your project needs to connect to a government system, ask early whether the connection goes through GDX or directly to the legacy system — the two paths may carry different approval steps and approvers.

The security review cycle: the step that eats time but rarely appears on a timeline

Before a project gets access to a live government system, most projects have to pass a security review run by the agency's own internal IT security team — a separate step from central standards and platforms like TGIX or GDX. That review typically covers source code review, vulnerability scanning, requests to open specific firewall rules, and sometimes documentation proving the new system follows the agency's own data-exchange standard. Some agencies also require a separate NDA for the team accessing the data, and assign a classification level to the data being connected, which determines who on the team is even allowed to see the real records.

The problem is that this queue is not something the development team controls. It runs on the security team's own schedule, which may already carry requests from several other projects. A plan that assumes approval happens "as soon as it's requested" is usually the exact point where the whole timeline slips — especially when the review turns up a vulnerability that has to be fixed and resubmitted, adding time nobody budgeted for. The safer approach is to ask the agency, before the contract is signed, what this process actually involves, who signs off at each step, and how long it has taken on past projects.

The evidence agencies commonly ask for includes a third-party penetration test report, an information-security certification for the development team if one exists, and sometimes a signed letter from an authorized officer confirming the new system will not store or forward data outside the agreed scope. These documents take weeks to prepare. A team that does not know it needs them in advance will not have them ready when asked.

When none of this caution applies

None of the above holds in every case. If the agency already has formal API documentation, a data dictionary that matches the live system, and has been through this kind of external connection before with a process that has settled down, this work barely needs extra time beyond a normal schedule. The risk this article describes comes from uncertainty in documentation and process, not from connecting an old system to a new one as such. An agency that has already invested in a central API gateway and documentation that stays current often makes later integration projects faster than the team expected.

Objections we hear often

A common pushback is: "If we build too much review time into the proposal, we'll look slower than competitors during the bid." There is some truth to that, but the real problem is rarely the buffer itself — a reasoned, explainable estimate reads very differently from a padded number nobody can justify. The better fix is to put the terms for legacy connection and security review directly into the TOR from the start, so every bidder prices the same assumption instead of guessing at this risk independently.

Another objection: "Our team already tested it in Postman, so we should be ready to connect for real." Passing tests in a sandbox is not the same as passing the owning agency's security review, which examines source code, access controls, and compliance with its data-exchange standard — none of which Postman checks for you. Even a sandbox the agency provides is not quite the real thing, because sample data there is usually far cleaner than years of accumulated production records.

Where to start

Before writing any integration code, there are three things worth doing in parallel from week one of the project, rather than waiting until the connection is actually due to start.

• Ask for as much documentation and real sample data from the old system as you can get on day one, even if it is incomplete — the later a documentation gap surfaces, the more it costs the timeline.

• Ask the agency directly what its security review process looks like before granting production access: who approves it, and how long it has taken on prior projects. Put that number into the timeline instead of estimating it yourself.

• Agree on the exchange method (batch or real-time), character encoding, date format, and field mapping in a document both sides sign off on before any integration code gets written.

None of these three take long on their own, but they need to happen before it is too late for the timeline as a whole. It also helps to have one person on the project team who owns this specific risk and tracks the review queue and outstanding documents directly, rather than leaving it spread across the team until nobody can say what the real status is close to delivery.

Summary

Connecting a new system to a government agency's old one carries a cost that rarely appears in the quote: the time spent understanding a poorly documented system, and the time spent waiting in a security review queue before the connection goes live. Both are predictable if you ask the agency before signing the contract. A plan that reasonably accounts for both tends to read as more credible than one that never mentions them at all.

Superdev builds Enterprise-standard systems on Google Cloud and Microsoft Azure, and has been behind projects for large public- and private-sector organizations.

To discuss your project, reach us at 088-983-9386 or [email protected]. Our office is in Bang Kapi, Bangkok.