<p>It is quite difficult to migrate the databases without downtime, however, using some approaches you can do it with very minimum impact, nearly a zero downtime.</p>

<p>The main idea in this is to create new databases with new schema. Then make changes in your code. First migrate the data from the old database to the new database. Then make changes in your code such that it starts writing to both the databases, old and new. You need to decide a time (time when there will be least writes to the database). Then stop all the writes. Remove the old database and make sure all the writes should now happen to new database from now on. 
Then start the writes back. </p>

<p>In this way, you can achieve DB migration with minimal downtime.</p>

<p>You can check <a href="https://dzone.com/articles/safe-database-migration-pattern-without-downtime" rel="nofollow noreferrer">this</a> for a detailed information on how this can be done. </p>

CC BY-SA 4.0
2019-09-11T07:29:28.073Z
Thanks. Is this a common practice, and if so, are there libraries which make the pattern of read-failover from the new database easier?
avi
CC BY-SA 4.0
2019-09-13T17:10:54.347Z
Yes, you can say this is a common practice as this strategy provides very minimal downtime. About libraries, I am not completely sure. You may need to search as per your database requirement.
Samit
CC BY-SA 4.0
2019-09-10T19:09:14.200Z
2019-09-10T19:09:14.200Z
Samit
<p>Our company has broken up most of our large Monolith application into smaller Microservices and we have a clear plan on how to get new services on Kubrenetes into a CI/CD pipeline.</p>

<p>However, we still have some parts of our applications which have not been broken up because of their database dependencies and the fact that they require downtime to deploy because of DB Migration issues. Part of the problem is that we have a large number of stored procedures which contain business logic in them.</p>

<p>I've seen plenty of information about how to refactor code and APIs so that we can have Blue/Green/Canary deployments. But how do we this for DB changes or migrations without downtime?</p>

CC BY-SA 4.0
2019-09-11T08:00:25.660Z
related: https://devops.stackexchange.com/questions/742/what-practices-or-tools-enable-continuous-deployment-of-databases
avi
<databases><migration>
What strategies exist to transition DB Migrations with Stored Procedures to Continuous Delivery?
avi
# What strategies exist to transition DB Migrations with Stored Procedures to Continuous Delivery?

(Asked by: username_0 on 2019-03-16)

Our company has broken up most of our large Monolith application into smaller Microservices and we have a clear plan on how to get new services on Kubrenetes into a CI/CD pipeline.

However, we still have some parts of our applications which have not been broken up because of their database dependencies and the fact that they require downtime to deploy because of DB Migration issues. Part of the problem is that we have a large number of stored procedures which contain business logic in them.

I've seen plenty of information about how to refactor code and APIs so that we can have Blue/Green/Canary deployments. But how do we this for DB changes or migrations without downtime?

**Tags:** databases, migration

> **Comments:**
> **username_0**: related: https://devops.stackexchange.com/questions/742/what-practices-or-tools-enable-continuous-deployment-of-databases  

---

## 1 answers

### Answer by username_1 on 2019-09-10. Score: 1 | Accepted answer

It is quite difficult to migrate the databases without downtime, however, using some approaches you can do it with very minimum impact, nearly a zero downtime.

The main idea in this is to create new databases with new schema. Then make changes in your code. First migrate the data from the old database to the new database. Then make changes in your code such that it starts writing to both the databases, old and new. You need to decide a time (time when there will be least writes to the database). Then stop all the writes. Remove the old database and make sure all the writes should now happen to new database from now on.
Then start the writes back.

In this way, you can achieve DB migration with minimal downtime.

You can check [this](https://dzone.com/articles/safe-database-migration-pattern-without-downtime) for a detailed information on how this can be done.

> **Comments:**
> **username_0**: Thanks. Is this a common practice, and if so, are there libraries which make the pattern of read-failover from the new database easier?  
> **username_1**: Yes, you can say this is a common practice as this strategy provides very minimal downtime. About libraries, I am not completely sure. You may need to search as per your database requirement.  

---

