I have a product which has a un-normalized legacy data model which contain millions of records. This has cause problems when adding new features and with performance. Also this contributes to high storage requirements at data file level on databases. I'm looking into a finding some good architectural patterns which i can follow to migrate my data from this current legacy data model to a more normalize modern data model. Are there any good architectural patterns which i can make use of ?

closed as too broad by gnat, Jörg W Mittag, Doc Brown, BobDalgleish, Thomas Owens Mar 17 at 23:45

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.

  • 2
    Possible duplicate of Choosing the right Design Pattern – gnat Mar 2 at 17:39
  • Well my question is more focus on finding a architectural pattern for migrating a legacy data model to a new model. Its something similar to architectural patterns that are used when moving from a Monolith to Micro-service. – GAP Mar 3 at 4:54
  • 1
    @GAP: asking for a pattern is often interpreted on this site as "is there a canned, braindead cargo-cult solution for this problem", for which the literal answer would be "no, you need a specific solution, investing a lot of thoughts into this is mandatory". You could ask for an approach or tactics for your problem instead, however, in the current form, I guess there are way too few details in your question to give you the kind of specific answer your problem requires. – Doc Brown Mar 3 at 17:32

There isn't a particularly good way to transition to a new data model. Ideally you can design the new data model, migrate your data to the new model, and be done.

But many projects can't do that because such a change would be too risky and too big. You then need to find or insert a seam where you can change a part of the system, without these changes affecting the entire system. Such seams are typically some kind of abstraction, for example an interface between two components.

  • One strategy can be to migrate the canonical representation of the data but continuing to offer the old interface via database views. You can then remove the view after all users have been migrated to use the new datamodel.

  • Another possibility might be to first refactor the code using the database to only access the database through an interface that you control (→ repository pattern). You can then transition the datamodel while only having to change the code within this repository. Such a strategy can help to migrate one aspect of the datamodel at a time and reduces the risks of this migration. However, this may not be a good fit for CRUD apps.

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