Uncovering dependencies
We analyse database logs to see which programs, macros and users actually connect, including the ones IT never knew about.
Moving the data itself is often the smallest part. The effort lies in dependencies, converting code and proving that everything arrived intact.
We analyse database logs to see which programs, macros and users actually connect, including the ones IT never knew about.
A straight move to a current version, a switch of database engine or replacing the application at the same time. We set out the effort and risk of each.
Data types, sequences, stored procedures and triggers are translated, for example from PL/SQL to PL/pgSQL, and protected by tests.
Duplicates, orphaned records and broken character encodings are dealt with before the move, so the new system does not inherit old problems.
The bulk of the data is copied in advance, and on switch day only the changes since the last sync are transferred. Days often shrink to a single night.
Key queries and reports are timed before and after. If anything slows down, we tune indexes or queries before users notice.
To satisfy statutory retention, a readable copy is kept, either as a read-only database or exported to open formats.
No rehearsal, no switch. Only measurements against your real data volume reveal how long the outage will be.
Inventory of database, code and access, choice of target platform and a plan covering risks and costs.
Schema and code conversion, automated comparison of data sets and checks of key processes by your users.
At least two full runs with timings, followed by a fixed runbook for switch day.
The switch in the agreed window, a fallback on standby and a few weeks of closer support.
Let your business departments test, not just IT. Technical comparisons prove every record has arrived. Whether dispatch's monthly report still shows the same figures is something only dispatch will notice. Give each department a short checklist and a few hours of testing time before the switch date.
Frequently, since licence costs disappear and PostgreSQL holds its own for most business applications. It is not worthwhile if a packaged product supports only one specific database. We check that first.
With delta sync, one night or a weekend is enough for many systems. We know the exact duration after the second rehearsal, and you receive a timed plan with decision points beforehand.
The old system remains reachable in read-only mode, and a fallback is ready for as long as it makes sense. Individual missing records can be pulled across from the legacy data.
Not necessarily. It often makes sense to migrate only the active years and leave the rest in an archive that satisfies retention rules. That keeps the new system lean.
Wherever you choose: data centres in Austria or the EU, such as Exoscale, Anexia or Hetzner, or your own infrastructure. You sign a data processing agreement with the provider.
Which system or database is being replaced, and how long can the business stand still? We begin with an analysis.
Your enquiry has arrived
Our reply reaches you within one working day. Outages that leave your staff unable to work are dealt with first.
We could not find that town. Try another spelling, or choose whichever provincial capital lies closest; as everything is handled remotely, you get the same service in all nine Austrian states.