4

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?

Improve this question
3
  • 1
    Why a "big bang" approach where you change everything and not an incremental approach where you first replace the UI (using an abstraction to access the existing DB) and only later the DB?
    – Lucero
    Feb 17, 2017 at 10:15
  • we plan to add new features to CMS and Portal, and old project is a result of several teams and years and years of undocumented work. every change could be potential disaster :(
    – Robert
    Feb 17, 2017 at 10:48
  • 1
    I'm not suggesting to change anything on the old system, but rather replace one piece at a time. Since the DB stuff is in SPs, it should be possible to do so... "big bang" is more risk and uncertainity overall.
    – Lucero
    Feb 17, 2017 at 11:11

1 Answer 1

Reset to default
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.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.