Keep running and secure
The system stays as it is. You secure the environment, document the existing knowledge and define who does what in an emergency. Sensible when the application is stable in business terms and nothing about it is due to change.
Service /3
Legacy modernisation in Salzburg: replacement while operations continue.
Your core system carries orders, stock and invoicing. That is exactly why nobody touches it. We replace it module by module, and daily business carries on.
Legacy is not a verdict on the software, and certainly not on the people who look after it. Legacy means this: a system does its job, but every change to it costs more time, more coordination and more nerve than the one before. At some point the fear of intervening slows things down more than the technology itself.
We have worked at this point since 2003. Part of what is now on the table as a legacy system was built in the same years in which we were building. We know the decisions behind it, and in most cases they were the right ones at the time.
This page describes how to recognise the right moment, which four paths are open to you and what procedure allows a replacement without downtime. If you conclude afterwards that your system will hold for a few more years, that is a useful result.
As for the location, the picture is clear: search for legacy modernisation in Salzburg and you mostly find national providers who know the installed base only from a distance. We are based in the city of Salzburg, we come to your premises when needed and we look at the system where it runs. With grown applications that counts, because a considerable part of the operational knowledge sits in the routine actions of the people who work with it every day and appears neither in the source code nor in the documentation.
How you notice it.
Five signs from practice. None of them is a failure on the part of your IT department. They arise because a system stayed useful long enough to keep being loaded further.
- Sign 1
- Changes take longer than they used to. What took two days five years ago now takes two weeks. The task has stayed the same. What has been lost is the certainty of knowing beforehand what else the change will touch.
- Sign 2
- There is one person who has to be asked. A particular process, a particular calculation step, a particular interface: for that there is exactly one person in the company. If that person is unavailable, the project waits.
- Sign 3
- Figures are maintained outside the system. Alongside the application, spreadsheets have appeared in which the actual work happens. The system then keeps the archive only. The version that applies sits in a file that nobody puts under version control and that exists on several drives.
- Sign 4
- Updates keep being postponed. The operating system, the database or the runtime environment has been on the same version for years, one that no longer receives security updates. The upgrade is postponed because it is unclear whether the application would survive it.
- Sign 5
- New requirements fail at the connection. A web shop, a customer portal, a report or a language model is supposed to access the existing data. In business terms the project is undisputed. It stays on the shelf because the old system offers no usable interface and every access would have to be built by hand.
Four out of five signs do not mean you have to act immediately. They mean that from now on the decision belongs to you and no longer to chance. The alternative is the unplanned case: an outage, a change in staff or an external requirement that allows no delay. Then the calendar decides, and that is regularly the most expensive variant.
Why the timing matters.
The deadline is not set by the technology but by the availability of the people who understand the system.
In grown landscapes, system knowledge sits with people, not with documents. Anyone who has accompanied an application for fifteen years carries the reasons in their head: why one field is kept twice, why an order has two statuses, why a particular nightly job was never changed. If that person retires or moves to another employer, the reasoning goes with them. The software remains, its readability does not.
Replacing that person is no longer a reliable answer. Statistics Austria has measured how companies looking for IT staff fare: of the Austrian companies with ten or more employees that recruited ICT specialists in 2023, or at least tried to, two out of three reported positions that were hard to fill. The reason cited most often was too few applications. Counting not just the recruiting companies but all companies in a size class, the share rises with company size: of all companies with 250 or more employees, 44 percent reported hard-to-fill ICT positions, of those with 50 to 249 employees, 14.5 percent, and of small ones with 10 to 49 employees, 3.7 percent. Survey "IKT-Einsatz in Unternehmen", reporting year 2023.
The German market, from which many applications come, offers no relief to the Austrian one. The Bitkom study report "Der Arbeitsmarkt für IT-Fachkräfte" reports around 109,000 vacancies for IT specialists in the German economy. 85 percent of the companies surveyed complain about the shortage, 79 percent expect it to worsen further. Survey year 2025, with 855 companies with three or more employees surveyed.
For your project this means two things. First, the person who can explain your old system is still here today and may no longer be in a few years. As long as they are available, an assessment costs a fraction of what reconstructing the knowledge from the source code would cost. Second, you will hardly manage the modernisation with additional staff of your own, because those people are hard to find on the market. The realistic path runs through external capacity combined with your own people, who know the business side.
Sources
- Statistics Austria, press release "20 % der Unternehmen beschäftigen IKT-Fachkräfte", survey "IKT-Einsatz in Unternehmen 2024", reporting year 2023, around 6,600 companies with ten or more employees surveyed. statistik.at, PDF
- Bitkom Research, study report "Der Arbeitsmarkt für IT-Fachkräfte", survey year 2025, 855 German companies with three or more employees surveyed. bitkom.org, PDF
Four paths between keeping and rebuilding.
The question is rarely "keep everything or rebuild everything". Between those poles lie two paths that in practice hold up more often than either extreme.
Encapsulate and open up
The old system stays untouched at its core and gets a clean interface to the outside. New applications, reports or AI functions access it through that interface instead of reaching into the old structure.
Replace step by step
One area after another moves onto a new foundation while the rest keeps running. After each step a piece of the old system is switched off and a piece of the new one is in service. The most common path in our projects.
Build new
The application is built from scratch while the old one keeps running until the switchover. Defensible when the business process itself changes fundamentally and rebuilding the existing system would cost more than a new build.
Which path holds is decided by the state of your system: the data model, the number of interfaces, the operational knowledge available and how stable the process itself is in business terms. We therefore commit only after the assessment and justify the recommendation against what we saw in the system.
Replacement without downtime.
A modernisation is decided by the switchover: the day the business departments are supposed to work with the new state. That is why the procedure is fixed before the first line is written.
Stage 1
Assessment
We look at what actually runs: data model, interfaces, nightly jobs, the places where people help things along by hand every day. The result is a written set of findings with risks and a recommendation for one of the four paths, together with a proposal for how to cut the first sub-area. The assessment therefore answers the question "which path for this legacy system, and where do we start". If instead you want to know whether the structure of a system carries load at all and what it will cost over the coming years, the architecture review is the right place.
Stage 2
Setting the cut
From the findings, the first sub-area is selected: small enough to be finished within a few months, large enough to be noticeable in daily operation. Along with it, the boundary is defined at which old and new talk to each other.
Stage 3
Parallel operation
New and old run side by side on the same data for a defined period. The results are compared and discrepancies clarified before anyone is switched over. This costs time, and it is precisely why the switchover later turns out to be unspectacular.
Stage 4
Switchover with a fallback
Switching happens area by area, not as one single event. For every switchover it is agreed in advance how success is measured, how long the old version stays reachable and what the way back looks like. The fallback is rehearsed once before the switchover, so that nobody has to improvise if it is needed.
Stage 5
Acceptance and handover
Acceptance happens per stage, not in one block at the end. Documentation, source code and operational knowledge go with it. Whoever built the software is still reachable five years later.
This procedure is slower than a switchover over a weekend, and that is the point. Every stage has its own benefit, its own acceptance and its own way back. You can pause after any stage, move the budget to another project and continue later, without a half-finished state being left in production.
Why we do not tear down
We built what is called legacy today.
A provider that has been on the market for only a few years mainly sees disorder in a grown system. We see twenty years of decisions made under real conditions: limited budgets, deadlines, departments that rightly wanted exceptions. Those exceptions now sit in the source code as special cases, and nearly every one of them had a reason.
That is why no modernisation of ours begins with a list of what was done wrong. It begins with the question of which part of the existing system still creates value. The part that no longer delivers that value is replaced, in that order and with that burden of justification.
This is also the founding idea of the company: replacing outdated structures and technologies while building on the proven knowledge of the generations. The sentence has been in the company profile since 2003, and it still describes the order in which we work.
Frequently asked questions about legacy modernisation.
The questions that regularly come up first in initial consultations.
How long does a legacy modernisation take?
That depends on the path chosen. Securing continued operation is done in weeks. Encapsulation with a clean interface usually takes a few months. A step by step replacement runs for months to years depending on scope, but it is cut into stages that go into service individually. This can only be stated reliably after an assessment, and for a mid-sized system that assessment takes a few weeks.
What happens to the existing data?
As a rule the data is the most valuable part of the old system and is migrated in full. Before every switchover a migration runs against test environments, followed by a comparison between the old and the new state. The switchover only happens once the results match. Historical data that is no longer needed in daily operation remains accessible in a readable archive.
What happens if the switchover fails?
For every stage it is agreed before the switchover how success is measured and what the way back looks like. The old version stays operational for an agreed period. Because switching happens area by area and not as one single event, a step back always affects only one area and never the whole company.
Who trains our staff?
We do. Training happens per stage and shortly before the respective switchover, not months in advance in one block. In practice a step by step replacement usually needs only a few hours per area, because for the users only one section changes at a time.
What happens to the old system in the end?
It is switched off in an orderly way. At the end of each stage we record which parts of the old system can go out of service, which data is secured beforehand and which licences or maintenance contracts are no longer needed. With older systems, these saved operating costs are often the part of the calculation that is forgotten first.
Do we have to commission everything from you?
No. The assessment can be commissioned as a service in its own right and ends with written findings that belong to you. You can continue with them internally or present them to another provider. We prefer a sound basis for a decision over a contract based on an assumption.
How does the assessment differ from the architecture review?
In the question it answers. The assessment presupposes a specific legacy system and answers which of the four paths carries it and how the first sub-area is cut. It is the first step of a replacement and can be credited against one if it follows. The architecture review answers the question before that: whether the structure of a system carries load, which risks it holds and in which order they should be dealt with. It presupposes no legacy system and is also commissioned for planned new builds. If your legacy system is settled and replacement is the topic, start here. If the question is whether at all, and in which direction, start with the review.
Start with an assessment.
A manageable first step with a fixed end: we look at your legacy system and deliver written findings with risks, a recommended path and the cut for the first sub-area. What happens next is your decision.
