0

I'm working on a project in which we are incrementally replacing an existing application. By incrementally I mean some features will be developed and shipped in the new application, and those features will be "deprecated" in the old application, but still available. The deprecated features will then be removed from the old application in a future release.

This means that existing data needs to be imported into the new application, as well as new data created using the old application.

One potential solution is to set up methods to import data from the old database, and run those each time any new data is entered in the old database. This would mean that the data should probably be tracked to avoid trying to import every single row every time there's any change. I guess this could be done with a boolean field in the old database tables.

Am I on the right track here? Is there an established solution to this problem?

Improve this question
2
  • 1
    This is a topic which could fill a whole book (which makes is IMHO too broad for the QA format of this site). It depends heavily on the application, the increments, the old vs the new data model, the need for consistency, time constraints, the technology involved, and at least dozen other things. Commented May 15, 2017 at 5:39
  • A book like this one for example: 'Refactoring Databases: Evolutionary Database Design' by Scott J Ambler and Pramod J. Sadalage, see martinfowler.com/books/refactoringDatabases.html and also here agiledata.org/essays/databaseRefactoring.html Commented May 15, 2017 at 12:28

1 Answer 1

Reset to default
1

The book 'Refactoring Databases: Evolutionary Database Design' by Scott J Ambler and Pramod J. Sadalage describes approaches to incrementally migrate data of an existing application to a new application. Have a look here to get some ideas what the book is about.

What you describe is basically creating a completely new database for the new application and then sync it with the old database of the old application. Keeping both databases in sync will be hard.

If old and new applications are very different and the old application will die very soon, then that is a possible solution. This allows you to start with a new database schema from scratch.

Otherwise I would rather point the old and new application to the same database and apply the techniques as described in the book. This is more incremental than having two different databases and supports the scenario of having the old and new version running in parallel.

Improve this answer
4
  • This is very useful insight. In my case, it won't be as complicated though, since I don't need to keep two separate databases synced. I think we can arrange for only allowing data entry from one application at a time, so the data import will be in one direction. Commented May 15, 2017 at 14:24
  • @Hassan: Then your scenario can be boiled down to a sort of integration scenario where you keep data between two application synchronized. Export data from old database and then import it into the new database. The incremental part is not such a big deal in your case. Commented May 15, 2017 at 14:32
  • Do you know if there are established techniques for that, or is it a matter of figuring out what works best for each case? Commented May 15, 2017 at 14:34
  • You got to figure out what works best for each case. If you search around for keywords like 'migrate database', 'sync database', '...with different layout', '... different databases ...' you will get a lot of different approaches. Basically you can just use datatabase mechanisms (and completely ignore the application, might involve ETL techniques) or go through your application (like you suggested, involves handrolled export-import logic). Commented May 15, 2017 at 14:55

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.