MDS In a Application Life Cycle Environment RRS feed

  • Question

  • Hi

    I'm putting together an approach for managing MDS across an enterprise and I have come across an issue where I hope someone will be able to help.

    Lets consider the scenario from day 1 where the MDS Model version in production and in development are the same. The version in production gets updated by a user with new data. The version in Development model gets updated for example new entities, attributes, relationships etc

    We now have the situation where the 2 models are out of sync. However I now need to be able to validate the data in production against the new model. If the model changes are small then this can be easily managed by taking a model + data package off production into a testing area and apply the new model from development on top and validate.

    However if the model changes are drastic then we need a method of migrating the data in Production into a new model. To acheive this I need to be able to extract data ONLY from the Production model. I've had a look at the structure of how the MDS data is stored and its not entirely obvious how I would be able to acheive this. Has anyone been in a similar situation and can offer any advice on how I can acheive this?

    Any help would be great

    Kind Regards


    Wednesday, April 20, 2011 4:43 PM



    Hi John,

    I believe you've answered the first part of your question, so I'll focus on the last part: migrating data in a significantly changed model.


    To start with, I would recommend a practice where you begin by having both the old and new model constructs side-by-side in the new model.  For example, if you are replacing attribute "A" on your customer entity with attribute "B" or replacing entity "C" with entity "D", I would add to the model such that both old and new objects (A and B; C and D) coexist together temporarily until you can migrate your data.


    Second, I would create subscription views that expose the data that I want to migrate.


    Third, I would create simple SQL scripts that select from the subscription views (data in the legacy objects) and insert the data into staging (targeting the new objects).  You could develop and test your scripts in the test environment and then apply the scripts in production for the final migration.


    Once your data is migrated, you could decide if it makes sense to kill off the old model objects or just make them invisible to users via restricted security settings.


    Reference information on staging and subscription views:

    See blog entries:

    Importing Data by Using the Staging Process

    Staging Examples and Troubleshooting

    Staging information in BOL:



    Subscription view (exporting) information in BOL:




    Val Lovicz



    Monday, May 2, 2011 1:56 PM