5,000 Installations, No Interface: How an Environmental Office Automated Its Data Migration
A system changeover sounds like a job for IT. In practice, the work often lands with the specialist department, one record at a time. Here is how a German district resolved that bottleneck with Robotic Process Automation.
Some projects nobody sees, yet they dominate the working week for months. Migrating legacy data when a line-of-business system is replaced is one of them. This was exactly the task facing the environmental office of a German district: the installation data on water-hazardous substances had to move from the legacy system Komvor into the new specialist application PROSOZBau. On paper, a routine job. In reality, a mountain of around 5,000 installations, and no technical bridge between the two systems.
The trigger: a system change with no bridge
The environmental office monitors installations that handle water-hazardous substances, from petrol stations to heating-oil tanks and much more. Each installation comes not only with master data but with sub-installations, volumes, hazard classes, inspection dates and contacts. All of it had to be transferred into the new system completely and correctly.
The real problem was not the volume of data but the absence of any interface. Neither the vendor of the old system nor the vendor of the new one offered an export or import function. A clean technical data transfer simply was not provided for. At first glance, that left only one option: retyping. By hand. All 5,000 installations.
The impulse to solve it differently came not from a requirements document but from an RPA awareness workshop that the district’s digitalisation office ran together with Lunatec. There, the data migration was identified as the ideal first case for automation.
The problem: 5,000 installations, by hand
Allowing roughly 30 minutes per installation for manual transfer and checking, the total comes to about 2,500 working hours. The team would have had to find that time on top of day-to-day operations, with no buffer, alongside every other task of a water authority.
Then there is the risk. Anyone retyping 5,000 records of volumes, hazard classes and inspection dates will make mistakes. With safety-relevant environmental data, that is not a cosmetic problem but a real one. Three figures summed up the starting position: 5,000 installations, no export function, no time to spare.
The solution: three bots, one queue, one Citrix session
Lunatec automated the migration with Robotic Process Automation based on UiPath, in an architecture of three bots working together, orchestrated through the queues of the UiPath Orchestrator.
The first bot reads an Excel table containing all the file references and hands each installation to the Orchestrator as an individual queue item. The second bot works through the items one by one, opens the relevant installation in Komvor and extracts all of its data, including every sub-installation. The third bot reads this prepared data and creates each installation fully automatically in PROSOZBau.
The technical hurdle lay in the environment: both specialist systems are available only inside a Citrix environment. The bot therefore runs on a virtual machine, starts the Citrix session via the browser and accesses the applications directly through UiPath Remote Runtime, exactly as a member of staff would. The entire processing therefore stays on-premises; no data leaves the district’s infrastructure.
Two details make the difference between “copying data across” and “migrating data cleanly”. First, the data clean-up: decommissioned installation parts are deliberately filtered out, and the total volume of each installation is recalculated automatically. Second, the quality assurance: the bot checks every field it reads for plausibility, covering presence, text length, data type and address validation. Anything that stands out is logged in the source table so it can be corrected in a targeted way.
Why classic RPA is the right choice here
This case is deliberately not an AI project. The migration follows clear, repeatable rules: which field belongs where, how the volume is calculated, which parts are active. Where the logic is unambiguous, classic RPA is the right choice, because it works in a way that is verifiable, traceable and auditable. The robot does exactly what a person would do, only faster, around the clock and without transfer errors.
The results
The impact is clear-cut. Around 2,500 hours of manual work fall away for the team; the entire migration effort shifts onto the bot. Per installation, processing time drops from about 30 minutes to roughly 10, that is, to a third. The transfer error rate is zero per cent.
One side effect is notable: while reading the data, the bot uncovered existing errors in the legacy records that had gone unnoticed for years. The specialist department was able to correct them in a targeted way, a gain in quality that had not even been planned for.
What the saved time is not also matters: it is not extra free time, but relief from a special task that would otherwise have had to be shouldered on top of daily operations. That is precisely what convinced the office. After the successful first phase, the migration of the heating-oil installations, the automation was extended directly to all remaining installation types. That second phase is currently under way.
What public authorities can take from this
System changeovers are nothing unusual in the public sector, and the data migration is almost always the bottleneck, especially when two proprietary specialist systems share no interface. The approach described here, connecting two unconnected Citrix applications via a queue and fixed rules, is transferable well beyond this single case.
The lesson is organisational more than technical: a migration for which a team would have run months of extra shifts can be handled as a single automated run, with better data quality at the end than retyping would deliver. And it rarely begins with a major programme, but often with a single question in the right workshop: which task is actually eating the most time here?