As a Solutions Architect specialising in Data, I have extensively worked on migrations: from on-premise to the Cloud, from one flavour of a vendor’s database to other flavours, and from one database to a different one. In my experience, the secret sauce of a successful migration is planning.

Bear in mind that a database contains data, but it also keeps the structure of the objects to keep the data (tables, documents, etc.), objects to access or run operations on the data (as views, stored procedures, macros, etc.), the security rules to read or modify the data, and logging mechanisms for security, and performance and capacity calculations.

The database is accessed by reports, different applications, batch and ETL tools, ad hoc queries and scripts. All these elements are enclosed in an ecosystem with specific security and infrastructure, and where the connections among the different aspects (database, reports, ETL. etc.) are defined according to business needs and requirements.

So migration is not only about moving data.

You can find here a document explaining the steps to plan for database migration. In coming posts, I will discuss specific migration examples, such as migrating from PostgreSQL to MongoDB.