Finding every consumer
Connection logs show which programs, macros, cron tasks and staff accounts touch the database. The spreadsheet nobody mentioned is the usual Monday-morning shock.
A Koper forwarding agent clearing goods through customs and running lorries across the region still relies on a transport package written for it long ago. Underneath sits Oracle 11g, and underneath that, Windows Server 2012 R2; both are past the end of security updates, and each renewal invoice is bigger than the last. Day to day, nothing seems wrong. The risk hides in what has grown around it: spreadsheets querying tables directly, a feed to the fleet telematics, a night-time file for the bookkeepers, PL/SQL routines whose author left long ago. Most managers worry about records vanishing. What we see far more often is subtler: the row count matches, yet a monthly report comes out a few euros different, surnames beginning with Č or Š land in the wrong place in a sorted list, and a search for “Č” finds no one because the legacy schema stored text as Windows-1250. Our job, then, is less about moving bytes and more about demonstrating that the result can be trusted. Engineers work through secure remote access, and go-live follows a runbook we have walked through twice or more.
Shifting the data might fill one evening. The real effort is the detective work beforehand and the checking afterwards.
Connection logs show which programs, macros, cron tasks and staff accounts touch the database. The spreadsheet nobody mentioned is the usual Monday-morning shock.
Stay on the same engine but upgrade, switch to PostgreSQL, or rebuild the application at the same time. You get money, risk and calendar time for each, side by side.
Column types, sequences, procedures, triggers and views translated, say from PL/SQL into PL/pgSQL, with a test proving each one behaves.
Mojibake from old code pages is repaired and the new database gets Slovenian collation plus correct upper and lower case rules, so searching and sorting treat č, š and ž as distinct letters.
Per-table record totals, hash comparisons and the reports each department depends on, run against both systems and compared line by line.
Bulk data is transferred days ahead, so go-live night only carries the final delta. An outage that might have lasted several days usually fits into a single evening.
For statutory retention, old records survive as a read-only database or as files in an open format anyone can open later.
We never promise a go-live date before a dress rehearsal. Downtime is predicted from timings taken on your real data.
Every consumer found, dependencies drawn, destination chosen and risks written down.
Schema and procedures converted, character sets and collation fixed, check scripts automated.
Complete timed trial runs, departments signing off their reports, and a runbook detailed to the minute.
The cut-over in its window, the go or no-go call at its fixed time, then close attention for some weeks.
Freeze changes before the move. For two weeks before the switch, nobody should add reports, fields or integrations to the old system. Any change in that period means the rehearsal no longer tests what will actually be moved. Put the freeze in the plan and tell everyone with database access.
Frequently, when licence fees hurt and your software can run on it. Where a vendor package is certified for one database only, switching engines is pointless, so that is checked on day one.
Because bulk data goes across beforehand, plenty of systems need just an evening or a weekend. After the second rehearsal you receive a timetable showing each hour of the cut-over.
A person you name before the switch, at a time written into the runbook. If checks are not finished by then, we revert, without arguing until dawn.
Rarely. Recent, active years go into the new system and older material sits in an archive that satisfies retention rules, which keeps the new database lean. Ask your accountant to confirm how long each document type must be held.
Location within the Union does not change your role as controller. Put a processing agreement in place with the host and update your record of processing activities. Keeping the database on your own hardware is also an option.
Tell us what you are moving off, roughly how big it is and the longest outage the business could live with. The first step is a short investigation.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.