Need help with system migration plan

Question

I need to rewrite old ASP.NET web forms VB application to new ASP.net mvc in c#.

Problem is that most of the old application logic for data inserting retrieval is written in stored procedures, which got messy over time, as old team was adding tons of stored procedures, which are doing the same thing, but contained small fixes over time, such as FetchById1, FetchById1_fixed etc..

I want to move away from that, and use ORM such as entity framework, but database design is not very ORM friendly. Data is scattered around, requires a lot of joins to query data, which would make EF queries very slow, especially because application is mostly read oriented. Aprox 50-60 people are inserting news article at the same time, and load can be up to 10-30k simultaneous users (according to analytics realtime).

Since main domain is around news articles and articles table, my plan is to add a database trigger which will trigger http call to a small service on our server, and signal id of newly created or updated article. Service will contain all necessary logic for mapping data from old to new database. (initial plan was to use some kind of message queue, but we do not want to touch legacy code of an old CMS).

This way, i plan to achieve that everything can function normally in our legacy system, but our team can develop applications which will be connected to a new database.

Am I on the right track? Should I consider some other approaches?

Answer 1

I do not like this approach because it does not seem to address your stated problem. It solves a different problem. Near-real-time data replication should only be needed if you need to support concurrent access, i.e. you cannot retire the old application before launching the new one.

Also, this:

Service will contain all necessary logic for mapping data from old to new database.

If you believe this is true, then there is no reason you cannot run exactly the same logic on the entire database.

The reality is that your migration will probably have problems. If you do a "big bank" migration, your migration scripts can generate a "fallout report" of records that fail conversion. It is possible in some cases you will need to manually adjust the source data to get the conversion to work. In that case, the automated process won't work-- only a manual conversion effort, with fallback reports and iterative improvement-- can do the job.

So

1. Write the best migration script you can
2. Run it and generate fallout reports
3. Examine the reports for any patterns, and improve your migration scripts if possible
4. Examine the reports for one-off issues and fix the source data
5. Repeat steps 2-5 until your fallout reports are empty.