Service · Custom software

System and database migration

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.

Oracle, SQL Server
to PostgreSQL or a current release
Validation
counts, checksums and report comparison
At least 2 rehearsals
on real data volumes
Rollback
with written decision points

What the work covers in practice

The move itself may take a few hours. The real effort goes into discovery beforehand and verification afterwards.

Agree the scope with the engineer who will do the work

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.

Choosing the target

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.

Schema and code conversion

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.

Turkish characters and collation

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.

Data validation

Row counts per table, checksums, and the key reports used by business units compared between the old and new systems.

A short cut-over window

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.

Archive and retention

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.

How we approach the job, from first call to handover

No cut-over date is set before a rehearsal. How long the outage really lasts comes from measurements on your own data volume.

01

Discovery

Connection inventory, dependency map, choice of target and a risk list.

02

Conversion

Schema and code conversion, character and collation settings, automated validation scripts.

03

Rehearsals

At least two timed full runs, report checks by business units and a minute-by-minute cut-over script.

04

Cut-over and watch

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.

Frequently asked questions

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.

Let's plan your migration

Which system or database do you want to leave, and what is the longest your operations can pause? We will start with discovery.

Availability
Weekdays 09:00-18:00 Turkey time (GMT+3); an answer follows by the next working day
Calls
By video, over Microsoft Teams or Google Meet

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.