3

We have a legacy system which will eventually be deprecated, at which point we will switch to using a new system.

What are the pros and cons of maintaining separate databases for the old and new system, versus incrementally adapting the original database?

closed as too broad by svidgen, Eric King, FrustratedWithFormsDesigner, gnat, JeffO Apr 5 '17 at 20:13

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • If you're going to downvote the question, please leave a comment with the reason. Otherwise, it's of no use to anyone. – Guybrush Threepwood Apr 5 '17 at 14:59
  • If you maintain separate databases, will they have the same structure, or does the new system have its own new database structure/design? – FrustratedWithFormsDesigner Apr 5 '17 at 15:59
  • 1
    I'm a simple man. I see the greatest wannabe-pirate of all times, I upvote. – Machado Apr 5 '17 at 16:09
  • 1
    Sorry. I have to VTC this. There's nowhere near enough information here to make a good analysis. Even a list of "pros and cons" depends massively on your particular situation. What your old schema looks like. What the new schema looks like. How messy the data is. Whether there will be conflicts between the two applications if they use the same data. Whether you need to and can sync the data during transition/development. Etc... – svidgen Apr 5 '17 at 17:22
  • 1
    To clarify what I mean, if it helps: If you're migrating from one CRM, with limited app-level "triggers" and constraints to another, where your schema doesn't change much, it may just be absurd to set up a new DB. On the other hand, if you're migrating from an "ultra legacy" schema (like Dynamics GP's) to ... anything else ... I can almost promise it's better to just start a new DB. ... Don't make a list of "pros and cons." Just assess the time and risk for your particular situation. – svidgen Apr 5 '17 at 17:26
4

I would have both systems running concurrently. Gradually migrating users/customers off the old one onto the new one.

The benefit of this is that you can test the new system with a subset of customers, avoiding a 'big bang' change over.

The downside is that you have to maintain two systems rather than one. However, if you break it down, you probably have several 'systems' in your company so it probably more like 11 systems instead of 10. which doesnt sound so bad does it?

It also forces you to really look at and automate your data migration process. as you will have to run it multiple times. This definitely results in a better product than the temptation of manual 'we are only going to do it once anyway' steps of the big bang approach

0

I fear this is largely opinion based.

I prefer to have one system, and have the upgrade be part of that systems life cycle. Even if your changing languages or technologies this is still generally "better" to me.

Pros

  • Users can be told it's coming
  • Users do not get to dictate that the old system was better so you have to keep it around forever.
  • Development continues on a straight(ish) path.
  • The changes can usually be made in smaller increments. Why do you have to redo the users table from scratch, why can't you just create a lost of columns to add, delete and modify and do that?
  • You avoid doubling the work. You may call system 1 "sun set" and say your pulling support, but you will still end up doing maintenance fixes on it.
  • you avoid doubling the load on your support staff. If you have "tech support" for your product you now only have to train new hires on one "system" not two.

Cons.

  • It can be a more complicated symphony of information to get users ready for the changes, support in place, etc. Failures to do so cause issue.
  • There will be regressions. It's not something you can avoid, specially when users are the ones that get to name what the regressions are.
  • If you have a crap roll out, then your stuck. You loose the ability to run some people on version 2 while your "big customers" use version one
  • Depending on your customers, they may well get very upset at having to retrain their employees. Specially true in B2B setups.
  • You will likely loose customers. Specially if you have a high number of "inactive but paying" customers, and have to go through "update your payment" process.

In the end though it comes down to right tool for the job. Sometimes you just have to run two versions, even though I usually am the first to fight for just a single version.

0

As they say, anybody can develop a system which is better than the current one. What takes skill is development of the set of crutches to walk from the old system to the new system without stopping the business processes.

If I had a number of paying customers, I'd go with two systems running in parallel, and a gradual switch-over. (If I don't have a bunch of paying customers, who do I rewrite the system for?)

Upsides:

  • Your business keeps running without any major interruptions.
  • Your customers don't face an abrupt change, and have ample time to migrate when / where needed.
  • You have a known good system to roll back to when a particular change in the new system turns out to cause problems, or even a catastrophic failure.
  • You have the best possible test suite, the live running system, as a reference for your new system while it's being built.
  • You can migrate customers or features gradually, and iron out any kinks under a light but real production load, as opposed to test load.

Downsides:

  • You have to design your functionality and data schemata for the split state during the co-existence period of the both systems, add hooks to help them communicate, etc.
  • You have to design the new system so that it could reasonably function when implemented partly, and piggy-back on the old system for the rest of functionality.
  • You have to replicate data between systems.
  • You have to be tolerant to the delays caused by data replication, and/or possible data inconsistencies due to that.
  • It will take significantly longer that a rewrite from scratch, and will cost more.

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