Migrating a database is one of the most delicate operations a company can undertake. That's why we don't take chances.
We audit, plan, and execute database migrations with guaranteed rollback, integrity validation, and zero tolerance for data loss—regardless of the engine, the volume, or the complexity of the schema.
What is a database migration and why does it happen?
A database is not static. Over the course of a company’s life, its data infrastructure needs to evolve: switching hosting providers, upgrading to a newer version of the database engine, adapting to new performance or scalability requirements, or undergoing a complete overhaul when the original data model no longer aligns with how the business has grown.
A database migration is the process of moving data from one system to another—preserving its integrity, adapting its structure to the new environment, and ensuring that the application that uses it continues to function properly afterward. It can be as straightforward as moving a MySQL database from one server to another, or as complex as transforming an entire relational schema into a NoSQL document structure, or vice versa.
What all migrations have in common is that they operate on live production data. No test environment can completely replace it. And when something goes wrong, the consequences are immediate and costly.
Do any of these situations sound familiar to you?
You switch hosting or infrastructure providers. Your database is hosted on a server that you're planning to phase out—whether due to cost, performance, or a change in architecture—and you need to migrate it to the new environment without losing data or interrupting service any longer than necessary.
You change the database engine. You have MySQL and need PostgreSQL. You have an SQL database and your architecture requires MongoDB. Or the other way around—you have MongoDB and the maturity of the business requires the consistency and relationships of a relational model. Switching database engines involves not only moving data but also adapting the schema, rewriting queries, and updating the backend data layer.
You transform the data model—from SQL to NoSQL or from NoSQL to SQL. This is the most complex and transformative migration. A normalized relational model in tables does not map directly to documents, and a flexible document schema does not automatically translate into relational tables with referential integrity. It requires data architecture decisions that have long-term consequences.
You modernize legacy infrastructure. Your data lives in Excel, Access, FileMaker, or any other system that wasn't designed to scale—and it needs to be moved to a real database before the volume or complexity makes it unmanageable.
You can update the ORM without changing the engine. You're using Sequelize and want to switch to Prisma. Or you're using Mongoose and need to upgrade to a version that supports strict schemas. The database engine stays the same, but you'll need to rewrite your models, queries, and migrations.
What sets a successful migration apart from one that goes wrong
A poorly executed database migration can result in partial or total data loss, unplanned downtime, and regressions in the application that relies on it. This is not a theoretical risk—it is what happens when the migration is performed without following the proper process.
Our process is designed to systematically eliminate that risk, not to manage it after it has already occurred.
Audit before touching anything.
Before designing any plan, we conduct an in-depth analysis of the current schema: tables or collections, relationships, indexes, constraints, data volume, data quality, and existing issues. The result is a written report detailing our findings and the risks identified. We do not begin any design work until this step is complete.
The design of the target scheme is validated with the client.
The new plan is designed and documented before any work begins. The client reviews and approves it. We don't start writing scripts until the design is finalized.
Rollback plan tested before execution.
Every project includes a documented and verified procedure for reversing the entire migration if something goes wrong. The backup is verified before execution. If the rollback fails, the migration is not executed.
Post-migration integrity validation.
After execution, we verify that the data has been imported correctly: record count, referential integrity, critical data checks, automated validation queries. Zero tolerance: if validation fails, a rollback is performed.
Execution in the maintenance window.
The migration is performed during off-peak hours, in coordination with the client, with active monitoring during and after the process.
For products with users active 24 hours a day, we offer migration with no downtime — a dual-write strategy that keeps both systems synchronized during the transition and allows for an instant switchover without any service interruption.
What each project includes
€3.000 – 8.000+
The base price of €3,000 covers migrations of up to 10 tables or collections using the same database engine. The price increases depending on the type of migration, the volume of data, and the project’s add-ons.
| Source database audit | Complete analysis of the current schema with a written report of findings and risks. Included in the base project price — it is the first step that determines the actual scope. |
| Target schema design | Modeling of the new schema with a source → target mapping document. Reviewed and approved before execution. |
| Migration plan | Step-by-step strategy with execution order, maintenance window, rollback plan, and validation criteria. |
| Verified rollback plan | Documented and tested procedure to revert the entire migration. The backup is verified before execution. |
| Migration scripts | Automated scripts to transfer and transform data. Documented and reusable. |
| Basic data cleaning | Deduplication, format normalization, encoding correction, and removal of orphaned records. |
| Integrity validation | Post-migration verification of record count, referential integrity, and critical data. Automatic rollback if it fails. |
| Backend data layer adaptation | Update of ORM models, rewriting of incompatible queries, and connection of the backend to the new database endpoints. The existing backend is adapted to work with the new database — no new endpoints or business logic are created. |
| Execution within a maintenance window | Migration coordinated with the client during off-peak hours with active monitoring. |
| 15-day post-migration support | Monitoring and resolution of any issue arising during the first 15 days. |
Does not include: new endpoints, new business logic, front-end changes, or ongoing maintenance.
Every scenario has its own complexities
Same engine
Switching servers, hosting providers, or versions without changing the engine. The most straightforward option, included in the base price.
Similar engine
Between relational databases such as MySQL and PostgreSQL. This requires type conversion, syntax adjustments, and engine-specific queries.
SQL → NoSQL
Denormalization of relational tables into documents. This requires a complete redesign of the schema and architectural decisions regarding embeddings versus references—which data is embedded within the document and which data is referenced externally.
NoSQL → SQL
Normalization of documents into relational tables. Design of relationships between entities, establishment of foreign keys, definition of referential integrity constraints, and migration of embedded data to independent tables with their own relationships. This is the migration that requires the most data architecture decisions.
Legacy → modern database
From Excel, Access, FileMaker, or CSV to PostgreSQL, MongoDB, or MySQL. Includes parsing and format conversion.
Examples of full project proposals:
| Project | Estimated price |
|---|---|
| MySQL → PostgreSQL (15 tables, ~50k records) | ~€3,400 |
| Excel/CSV → PostgreSQL (20 files, data cleaning) | ~€4,200 |
| MongoDB → PostgreSQL (12 collections, normalization) | ~€5,500 |
| PostgreSQL → MongoDB (25 tables, zero-downtime) | ~€6,800 |
| SQL Server legacy → PostgreSQL (40 tables, 1M+ records) | ~€8,500 |
It depends on the type of migration and the add-on chosen. A standard migration executed within a maintenance window involves a controlled period of unavailability agreed with the client — typically between minutes and a few hours depending on volume. For products with users active 24/7 where any downtime is unacceptable, the zero-downtime migration keeps both systems synchronised during the transition and allows an instant cutover with no service interruption. It's the add-on we recommend for any product in production with continuous traffic.
The rollback plan exists for exactly this. Before executing the migration, the backup is verified and the reversal procedure is tested. If the post-migration integrity validation fails at any point, the rollback is executed immediately. The client is never left with a database in an inconsistent state — either the migration completes successfully or we return to the starting point with data intact.
Yes — the backend data layer is included in the base price. That means updating ORM models, rewriting queries incompatible with the new engine, and connecting to the new database endpoints. What's not included are new endpoints, new business logic or frontend changes — that's development and is quoted as a separate project.
Yes. The initial audit exists precisely for this — to understand the schema and data as they are before touching anything. If during the audit we find serious structural issues that make the migration unfeasible under the project's conditions, we communicate that before committing to any price or execution date.
It depends on the problem you're solving. A SQL schema that started being used for data with highly variable structure may benefit from NoSQL. A document database that has grown with complex relationships and transactional consistency needs may benefit from SQL. There's no universal answer — it's an architectural decision we assess during the initial audit with the actual business requirements as the starting point.
The 15-day post-migration support covers any issue that appears in production as a result of the migration. For ongoing maintenance of the new database — backups, updates, monitoring — the DevOps retainer is the natural next step.
CONTACT
Let’s talk about your project.
Tell us what you need and we’ll get back to you within 24 hours with an initial proposal and a personalized action plan.