Database migration is one of those projects that every growing business eventually faces — and one that gets delayed for as long as possible because it feels risky. The data that runs your operations has been accumulating for years. Moving it to a new system feels like open-heart surgery: high stakes, complex, and full of things that could go wrong.
The reality is that a well-planned database migration is not nearly as dangerous as its reputation suggests. Done properly, it is methodical, reversible at each stage, and far less disruptive than continuing to operate on a system that is slowing your business down. This guide covers how to approach it.
Why businesses need to migrate their databases
Database migrations happen for several reasons. Legacy systems reach end-of-life and lose vendor support. A business outgrows the capacity of its original database and performance begins to degrade. A company moves to cloud infrastructure and needs to shift data from on-premise servers. Two businesses merge and their separate data systems need to be consolidated. A new application requires a different database technology than the one currently in use.
For Irish SMEs, the most common trigger we see is a combination of the first and third: a business that set up its systems five to ten years ago, running on an ageing on-premise server or an outdated database platform, that needs to move to a modern cloud-hosted alternative to improve reliability, reduce IT overhead, and support remote access.
Whatever the trigger, the underlying challenge is the same: moving data from one system to another without losing anything, corrupting anything, or causing extended downtime.
The four types of database migration
Storage migration moves data from one physical storage medium to another — from a local server to a cloud storage provider, for example — without changing the database structure or technology. This is the simplest type.
Database engine migration moves data from one database platform to another — from MySQL to PostgreSQL, from Microsoft SQL Server to a cloud-native database, from an Access database to a proper relational system. The structure and queries may need to change, which adds complexity.
Application migration involves moving a full application stack, including its database, to a new environment. Often this means moving to a cloud platform like AWS, Azure, or Google Cloud, with the database migrated as part of the wider project.
Data consolidation merges multiple databases — from different departments, acquired companies, or parallel systems — into a single unified database. This is typically the most complex type, involving data mapping, deduplication, and reconciliation across systems that may have very different data models.
The six stages of a successful migration
1. Audit and document the current state. Before touching anything, document exactly what you have: database size, number of tables, relationships between tables, data types, any stored procedures or triggers, current performance baselines, and which applications or reports depend on the database. This documentation is your safety net throughout the project.
2. Define the target state. Decide precisely what you are migrating to and why. Identify the target database platform, hosting environment, and any changes to the data structure that are needed. If you are changing database engines, identify where the schemas are incompatible and how those differences will be resolved.
3. Build and test the migration scripts. The actual migration is performed by scripts that extract data from the source, transform it where necessary, and load it into the target. These scripts need to be built and tested exhaustively on a copy of production data — not on production itself. Run the full migration multiple times in a test environment, validate the results, and time how long it takes. This gives you a realistic estimate of the production migration window.
4. Migrate a non-production copy first. Before touching live data, perform a complete migration of a recent production snapshot to the target environment. Run your applications against it. Run your reports. Have users test it. Find the problems here, not during the live migration.
5. Execute the live migration with a rollback plan. Schedule the live migration for the lowest-traffic period. Communicate downtime windows clearly. Run the migration scripts, validate data integrity on completion, and switch over. Critically: keep the original system intact and reachable for a defined period after go-live so that if a critical problem is discovered, you can roll back without data loss.
6. Monitor, validate, and decommission. In the days and weeks after go-live, monitor performance, check for query anomalies, and validate that data is as expected. Only decommission the original system once you are confident the migration is clean and stable.
The most common cause of migration failure is skipping or rushing stage three — building and testing migration scripts on real data. Migrations that fail in production almost always fail because edge cases in the data were not discovered during testing. Real production data is always messier than you expect.
Data quality: the problem nobody wants to talk about
A database migration is often the moment when years of accumulated data quality problems become impossible to ignore. Duplicate customer records. Inconsistent date formats. Fields used for purposes they were never intended for. Legacy codes that no one fully understands.
The migration forces a decision: migrate the mess as-is, or clean it up as part of the project. Neither answer is obviously right. Cleaning data during migration extends the project significantly and introduces its own risks. But migrating dirty data to a new system means your new system starts life already compromised.
Our recommendation for most SMEs: separate the concerns. Migrate the data as accurately as possible to the new system — preserving the existing structure and content — and then address data quality as a distinct follow-on project with the new system in place. Trying to solve both problems simultaneously rarely ends well.
What a realistic migration project looks like for an Irish SME
A medium-sized Irish business migrating an operational database of moderate complexity — a few dozen tables, several hundred thousand records, a handful of connected applications — from an on-premise SQL Server to a cloud-hosted equivalent can typically expect:
Two to four weeks of discovery, documentation, and planning. Two to three weeks of script development and testing. One to two weeks of pre-production validation. A migration window of four to twelve hours for the live cutover, depending on data volume and complexity. Two to four weeks of post-migration monitoring before the old system is decommissioned.
Projects that take significantly longer usually do so because the source system was more undocumented than expected, data quality issues were more severe than anticipated, or scope expanded to include application changes that weren't originally in plan.
Planning a Database Migration?
We help Irish SMEs plan and execute database migrations with minimal disruption. Start with a free audit of your current data infrastructure.
Book My Free Audit →