Connection inventory
From database logs we list every application, macro, scheduled job and user that connects. A forgotten Excel report is the most common surprise on cut-over morning.
Imagine a customs and international freight firm in Mersin. The transport management system it commissioned years ago sits on Oracle 11g, running on Windows Server 2012 R2. Both are out of security support, and the licence bill strains the budget every year. The program seems to work fine, but the danger lies out of sight: Excel reports wired straight into the database, an interface to vehicle tracking, nightly files for Logo in accounting, and stored procedures nobody fully understands. What people fear most in a migration is losing data. What actually happens more often is silent corruption. Every record arrives, yet a report shows a different total, customer names with Turkish letters sort in the wrong order, or records starting with “İ” cannot be found in a search. That is why the heart of our work is not moving data but proving it moved correctly. Everything is done over remote access, and the cut-over follows a script that has already been rehearsed.
The move itself may take a few hours. The real effort goes into discovery beforehand and verification afterwards.
From database logs we list every application, macro, scheduled job and user that connects. A forgotten Excel report is the most common surprise on cut-over morning.
An upgrade to a current release of the same engine, a switch to PostgreSQL, or renewing the application as well. Cost, risk and duration are compared for each route.
Data types, sequences, stored procedures, triggers and views are converted, for instance from PL/SQL to PL/pgSQL, and each is verified by a test.
Encoding errors common in older systems are cleaned up, and Turkish sorting and case rules are configured correctly on the target. That way “ı” and “i”, or “İ” and “I”, stop getting mixed up in searches and sorted lists.
Row counts per table, checksums, and the key reports used by business units compared between the old and new systems.
Most of the data is copied ahead of time, and only the latest changes move on the day. Downtime that would have lasted days often shrinks to one night.
A readable copy of the old data is kept to meet Tax Procedure Law retention duties, either as a read-only database or as an export in an open format.
No cut-over date is set before a rehearsal. How long the outage really lasts comes from measurements on your own data volume.
Connection inventory, dependency map, choice of target and a risk list.
Schema and code conversion, character and collation settings, automated validation scripts.
At least two timed full runs, report checks by business units and a minute-by-minute cut-over script.
The switch in the agreed window, go or roll back at each decision point, then a few weeks of close monitoring.
Write down in advance who calls a rollback, and by what time. When something goes wrong on migration night, indecision is the biggest danger. Put it in the script: if validation is not complete by a given hour, you return to the old system, and name the person who makes that call. That single line saves an argument that could otherwise last until dawn.
If licence costs matter and your application allows it, usually yes. If a packaged product you rely on supports only one specific database, a switch makes no sense. That is the first thing we check.
With an advance copy and a final sync of recent changes, one night or a weekend is enough for many systems. The exact figure is known after the second rehearsal and reaches you as a timed plan.
Generally not. Changing the database and the application at once makes it much harder to pin down the cause when something breaks. Migrating first and modernising afterwards is usually safer.
No. Moving the active years into the new system and keeping the rest in an archive that satisfies retention rules keeps the new system fast and tidy.
Moving a database containing personal data out of Turkey triggers the KVKK rules on cross-border transfer. A data processing agreement is signed with the host, and the legal basis for the transfer is settled with your adviser. We can also keep the data on your own server if you prefer.
Which system or database do you want to leave, and what is the longest your operations can pause? We will start with discovery.
We have your enquiry
A reply will reach you by the next working day at the latest. If your message says work has come to a halt, it goes to the top of the pile.
No such city in our list. Try another spelling, or just pick the closest big city: we work entirely over remote connections, so nothing about the service changes from one province to the next.
The only cookies here are the essential ones: they keep the site running and remember the city you picked. Nothing is used for advertising or tracking. See our privacy notice for more.