Database Migration Services
Hand us the migration. Our engineers run it on the software we wrote - from inventory through a tested cutover - across the database pairs we have been building converters for since 2001.
You do not need another project to run
A migration changes more than rows. It changes what your application sees, which queries still return the same answer, who has rights on which server, and how much of the night you spend watching a progress bar. Most of that work is not interesting, and none of it is the work your team was hired to do.
We take the whole thing. You approve the plan and the cutover window; we do the rest and show you the evidence at each step.
How it runs
Five stages. Each one produces something the next is built on.
Find out what is actually there
Schema, dependencies, database code, the shape of the data, and what your operation cannot tolerate. The plan comes out of that, not out of a table count. This stage costs you nothing and you keep the plan whatever you decide next.
Convert, and check it converted
Schema and types first, with every column that cannot map cleanly decided rather than guessed. Then the parts that usually surprise people: keys, indexes, and the constraints that only fail once there is data behind them. The awkward cases surface while there is still time to do something about them.
Move the data inside the window
Large tables get the method that suits them and the rest get the fast one. A dropped connection becomes a resumed run rather than a restart - the thing that turns a four-hour window into a lost weekend.
Switch over when the numbers agree
We rehearse it first, compare both sides until the counts match, run the real switch in the window you chose, and stay with you afterwards until the new database is boring. You get a way back if it is not.
Run both until the old one can be retired
The new database going live is rarely the end of the old one. We set up the ongoing replication so the two stay in step for as long as you need - while applications move across one at a time, or while a legacy system is wound down - then hand it over running on your own machines. It is a job in the product, not a service you rent from us.
Which engine keeps them in step
Decided by what your DBA will allow, not by us. We check before designing around either.
Trigger-based sync
- Every pair we support, legacy formats included
- Creates a tracking table and triggers inside your source database
- One direction only where FoxPro or DBF is one side
DBConvert Streams
- Reads the database log - never touches your source schema
- MySQL and PostgreSQL only
- Needs replication privileges the source owner may not grant
Our engineers, our software
Most people who do this for a living assemble somebody else's toolkit and work around its blind spots. We wrote ours - the same converters thousands of companies run themselves, across more than 50 source and target combinations.
So when your migration hits the thing that always goes wrong on that particular pair, we are not reading someone's documentation. We wrote the code that raises the error, and we can change it.
When the person who wrote it has left the building
The developer retired. The vendor closed in 2009. The documentation is a spreadsheet somebody's predecessor kept. And every firm you have asked for a quote has gone quiet, because none of them can open the files.
We still maintain the readers
dBase and xBase, FoxPro, InterBase, Firebird, Access, IBM DB2 - formats most migration firms never supported and the rest dropped years ago. We have been writing and shipping converters for them since 2001, and they are still in the product because customers are still running those systems in production.
We will open it and tell you what is in there
Usually the hardest question about an old system is not how to move it - it is what it actually contains, because nobody left is able to say. We read the schema, the indexes, the keys and the data, and give you a plain account of it. That answer is worth having even if you never migrate.
What this is not: we do not take over your VB6 or Delphi application, and we do not rewrite the business logic inside it. We work on the database - getting the data and the structure out of a format nobody else reads, and into something current that your team can build on.
Where our line is
Better to read this now than to find out in week three.
Data, structure, keys, indexes
Every pair we support. That is the product, and it has been for two decades.
Application code
Not ours. We will tell you what the database change forces your application to do differently. Doing it is your team's job or your integrator's.
And if the honest answer is that you should not be doing this migration, or should not be paying us to do it, that is what the first stage is for.
Your data
What we ask for, and what happens to it.
Planning needs no production data. Schema, a sample you choose, and a log or two are enough to plan and price the work. Access to live systems is a later conversation, and sometimes never - a migration can run from a database dump.
Non-disclosure agreement. We will sign yours, or send you ours. Mention it in the first email and it is settled before anything is sent.
We are an EU company. Slotix s.r.o. is registered in Slovakia, so for customers in the EU your data does not leave it. Where we process personal data on your behalf we sign a data processing agreement.
Credentials stay on your side. Access through your VPN or jump host, for named people, with credentials kept in your vault rather than ours.
We delete what we were given. Working copies are removed when the engagement ends, and we confirm the deletion in writing.
Regulated data. If your data falls under HIPAA, financial or other sector rules, say so in the first email. We agree in writing how it will be handled before any of it moves.
This is not support, and support is not this
If you own a licence and something is not working, that is support - free, with no time limit. Questions about our software, diagnosis of what is going wrong, and defects in our own products stay free however long they take and whoever turns out to be at fault. Nothing on this page is a way of charging for that, and we will never quote you a price in the same message as an unsolved error.
This page is the other half: we do the work instead of explaining it. Always scoped and priced before it starts, never invoiced afterwards for something you did not agree to.
Invoiced directly by Slotix s.r.o. by bank transfer, matched to your purchase order number. See buying through procurement for the vendor details your purchasing team will ask for.
Databases and clouds we work with
Over 50 source and target combinations, in products we wrote ourselves.
Access
Amazon Aurora
Amazon RDS
Azure SQL
Citus
CockroachDB
dBase / xBase
DigitalOcean
EDB Postgres
Excel
Firebird
FoxPro
Google cloud
Greenplum
Heroku
IBM DB2
InterBase
JSON
MariaDB
MySQL
Neon
Oracle
Percona
PostgreSQL
SingleStore
SkySQL
SQL Server
SQLite
Supabase
TiDB
Vitess
YugabyteDB
If your source is not on this list, say so in the first email. We will tell you plainly whether we can help - IBM i and AS/400 sources are the usual case where the answer is no. New to how synchronization works? Our overview of database synchronization compares the four approaches and what access each one needs.
Three things and we can start
What you are moving, where it has to go, and what your business cannot tolerate - a deadline, a downtime limit, a system that must stay live.
We come back with the path, what it will cost, and who does what. If the honest answer is that this is not work we should take, you get that instead, and it costs you nothing either way.