Practical guide 01 / 05
Government legacy modernisation should make change safer, not simply make the technology newer. The practical goal is to reduce dependence on fragile interfaces, undocumented business rules and a small number of people who know how the system works.
The answer for public-sector IT leaders
Start with a specific service bottleneck. Map its dependencies, agree the intended outcome and establish how success will be tested. Where appropriate, a Strangler Fig approach lets an existing application continue operating while selected capabilities move to new components. Martin Fowler describes this pattern as an incremental alternative to replacing an entire application at once. [1]
A digital front door with a manual back office
Consider an illustrative application process. A resident submits a form online. An officer rekeys the data into a case-management application, stores the attachments in a document system and updates a separate tracking sheet. The portal works. The complete service is still fragmented.
A redesign focused only on the user interface can leave every operational dependency untouched. A better starting question is: which change do we keep postponing because the consequences are too difficult to predict? That question connects architecture to the actual work of a public authority.
Why public-sector application modernisation stalls
The important interfaces are not always the official ones
A nightly file transfer, a direct database query or a fixed date format can be more business-critical than the documented API. Map producers, consumers, data ownership, processing deadlines and failure consequences. Include manual workarounds. An application inventory is useful, but it is not yet a dependency model.
Business rules disappear into integration code
An API contract needs meaning, not just valid JSON. What does an approved status represent? Which timestamp is authoritative? Who can reverse a change? Reimplementing these rules in an integration adapter can create a second, poorly documented business application. Keep business ownership explicit and avoid duplicating authoritative logic without a controlled design.
Data migration starts too late
A completed import is not evidence of a successful migration. Record counts, totals, references, attachments, access rights and retention requirements must reconcile. Create representative test cases early, with approved test data and a procedure for resolving discrepancies. Decide how changes made during migration will be captured and checked.
The diagnostic test: Can the team explain what happens to a case when an interface fails halfway through processing? If not, the first investment should be visibility and control, not a larger platform.
The solution: decouple one capability at a time
Establish a narrow, versioned integration boundary
Choose one business operation: create a case, attach a document or retrieve a processing status. Specify the request, response, permissions, errors and compatibility rules. An adapter translates that contract into the legacy application’s supported interface. New consumers no longer need to understand the application’s internal tables.
For German public services, FIT-Connect is an example of standardised transmission between online services and administrative systems. Assess its fit for the specific service; it does not replace internal validation or a complete integration architecture. [2]
Keep one authoritative writer for each data domain
Uncoordinated updates in old and new systems create inconsistent records. Make ownership explicit. Depending on the estate, use events, controlled exports or a reconciled migration run to move information. Stable identifiers and idempotent processing help prevent a repeated delivery from creating an unintended second case.
Treat operational knowledge as a deliverable
A repository is not a handover. Supply build instructions, environment definitions, dependency records, access design, monitoring and a tested recovery procedure. Integrate security checks into the delivery process; the NIST Secure Software Development Framework provides a recognised reference for doing so. [3] A receiving team should be able to build and operate the service without depending on undocumented knowledge held by the original supplier.
A delivery path with explicit decision gates
1. Bound the first engagement
Select a service bottleneck rather than the entire IT estate. Involve the service owner, operations, information security and data protection. Agree scope, test data, decision authority and acceptance. The first deliverables should explain the current dependencies, the material risks and the options to stabilise, decouple or replace the application.
2. Test the integration under realistic failure conditions
Include duplicate messages, missing attachments, expired credentials and a timeout after a successful write. A technical retry must not silently create a duplicate business action. Make contract tests and business reference cases part of the release pipeline, not a spreadsheet used only before the first go-live.
3. Introduce controlled production use
Start with a defined user group or case type. Read-only parallel comparison can validate outputs without creating two uncontrolled writers. Agree the change window, incident ownership and rollback plan before switching traffic. Reverting software does not automatically reverse business data already written. Reconciliation and compensation need their own procedures.
Acceptance should cover four outcomes
Business correctness: agreed reference cases produce valid results. Repeatability: repeated delivery does not create unintended duplicates. Recovery: a restoration test meets agreed objectives. Transferability: another team can reproduce deployment and explain the operational process.
Use the results to decide whether to expand, redesign or stop. The incremental approach loses its advantage when temporary adapters and parallel systems become permanent without an owner or retirement plan.
Build the business case around total change cost
Compare more than implementation prices. Include legacy maintenance, licences, interfaces, parallel operation, data cleansing, assurance, training and eventual exit. A replacement can appear inexpensive when these activities sit outside the proposal.
An illustrative calculation, not a customer result: 12,000 cases per year and four minutes less manual rekeying per case represent 800 staff hours. Allowing another 200 hours for review and exception handling leaves a theoretical 600 hours of capacity. That is not automatically a cash saving. A pilot must establish whether the time is genuinely released and how the service can use it.
Specify outcomes procurement can verify
Useful deliverables include documented interfaces, exports with metadata, acceptance tests, rights to project outputs, operating instructions and transition assistance. Define how data-model changes are handled and which evidence is supplied at acceptance. These requirements should be proportionate to the application and procurement route.
In Germany, section 97 GWB addresses competition, equal treatment and consideration of SME interests. It does not entitle a particular small supplier to an award. The contracting authority remains responsible for the appropriate procedure. [4]
Discuss the first modernisation boundary with Insight42
Bring one application, one bottleneck and one intended outcome. Insight42’s published services cover cloud, data, automation and technical delivery. [5] A focused initial assessment can be scoped around a dependency map, an interface proposal and a prioritised delivery plan. Confirm the scope and deliverables before commissioning work.
Contact: support@insight42.com. Describe the application and operational problem in general terms. Do not include personal case records, credentials or confidential documents in the initial message.
Frequently asked questions
Must the existing application be replaced?
Not necessarily. If it remains fit for purpose, maintainable and supportable, decoupling may be enough. Replacement becomes more compelling when essential requirements cannot be met economically or reliably. Compare practical options and their full lifecycle costs.
What if the supplier provides no API?
Check supported import, export and integration options, together with contractual rights. Direct database access and screen automation are not equivalent to a stable interface. Where an interim workaround is necessary, document its limitations, failure handling and planned retirement.
Does open source eliminate vendor lock-in?
No. Source availability can improve options, but practical independence also requires usable build artefacts, documentation, licence clarity and alternative operating capability. A handover exercise is stronger evidence than an open-source label.
What makes a sensible first work package?
It creates a testable service improvement without requiring the entire estate to change first. Scope, ownership, acceptance and recovery are explicit. Small scope does not automatically mean low risk: dependencies still need to be understood.
The takeaway: A modern application is one the organisation can change, operate and transfer with confidence. That is a more useful definition of digital sovereignty than the age of the technology stack.
Sources and technical references
[1] Martin Fowler: Strangler Fig
[2] FITKO: Was ist FIT-Connect?
[3] NIST: SP 800-218, Secure Software Development Framework 1.1
[4] Gesetze im Internet: § 97 GWB
Sources checked: 27 September 2026. Calculations and diagrams are illustrative.