How to get your data out of MDS before you lose access to it

To export from Master Data Services you use MDSModelDeploy.exe, the command-line tool on the MDS server. Run createpackage with -includedata and you get a .pkg file holding entities, attributes, attribute groups, hierarchies, collections, business rules, version flags and subscription views. What you do not get is your permissions, your file attributes, or any record of which downstream systems depend on what.

That distinction matters more than it sounds. Teams run the export, see a healthy-looking package, and conclude their implementation is safely captured. Then they rebuild elsewhere and spend weeks reconstructing a permission model nobody wrote down.

The export command

The tool lives on the MDS server, under the Configuration folder of the MDS installation. Run it from there, on the box — it is not a remote client.

MDSModelDeploy.exe createpackage
  -package  "C:\mds-export\Finance.pkg"
  -model    "Finance"
  -service  "MDS1"
  -version  "VERSION_1"
  -includedata

Drop -includedata and you get structure with no members — useful for moving a model shape between environments, useless as a migration artifact. Run it once per model. If you are not sure how many models you have, that is itself a finding worth writing down.

Worth knowing: packages are version-specific. A package built on one SQL Server release does not reliably import into a different one, which is precisely the situation you are in if you are exporting because of an upgrade. Treat the .pkg as an archive of record, not as your migration mechanism.

What the package quietly leaves behind

Permissions. User and group permissions are not in the deployment package. Everything you built across functional areas, model objects, and member-level access has to be recreated by hand. On a mature MDS install this is often the single largest undocumented asset you own. Screenshot the permission grids before you lose the web UI.

File attributes. Also excluded. If anyone attached documents to members, those attachments do not travel and need extracting separately.

Who consumes your subscription views. The view definitions are in the package. The knowledge of which ETL job, which ERP interface, and which report reads them is not, because MDS never held it. This is the item that causes go-live incidents, and the only way to build the list is to go looking before you cut over.

History. Transaction history and annotations stay in the MDS database. If you have a compliance reason to retain who changed what, plan to keep the database itself, or extract that history separately — the package will not carry it.

Take a flat SQL snapshot as well

The .pkg is a proprietary artifact that only MDS can open, which is an awkward property for a file whose job is to outlive MDS. Take a second export that anything can read. Subscription views are the right source: they were built to be consumed, they resolve codes and names properly, and they are plain views in the MDS database.

-- List every subscription view you have
SELECT  v.name AS ViewName, s.name AS SchemaName
FROM    sys.views v
JOIN    sys.schemas s ON s.schema_id = v.schema_id
WHERE   s.name = 'mdm'
ORDER BY v.name;

-- Then snapshot each one to a portable format
SELECT * FROM mdm.vw_Finance_CostCentre;

Write the results out as CSV and keep them beside the package. If a migration goes sideways two years from now, a CSV opens. A .pkg without a working MDS install does not.

A complete export, in order

1. List your models and versions, and decide which version is the one of record.
2. Run createpackage -includedata per model. Keep the packages somewhere that is backed up.
3. Snapshot every subscription view to CSV.
4. Capture the permission model by hand — screenshots or a written matrix, per functional area and per entity.
5. Extract file attributes if anyone used them.
6. Build the consumer list: every job, interface, and report that reads an MDS view. Ask the teams, then confirm by checking what actually queries those objects.
7. Note your business rules in plain language. They will not transfer as executable logic, and the intent behind them is easy to lose.
8. Verify: reimport a package into a test MDS instance and compare row counts against the source before you trust any of it.

Do this before the server changes

MDS is gone from SQL Server 2025, so upgrading the instance removes the web application and the tooling along with it. Export while the service is still running and you can still open the UI to check what the package captured. The Excel add-in is a separate casualty with its own timeline — it stopped working in April 2025 when Office disabled ActiveX, so if that was your extraction route, it is already closed.

Where the export lands

An export is only half a migration — something has to read it. Primentra's migration wizard takes MDS structure and data and maps models to models, entities to entities, attributes to attributes, including domain-based attributes and hierarchies. The permission model still needs rebuilding, because it was never in the package to begin with, but the structural work is mechanical rather than manual. The migration guide covers the full sequence, and validating a master data migration covers how to prove the result matches what you exported.

Frequently asked questions