Portal

Hello Joe,

It is not possible to import a 2025.1.11 model into a 2024.1.1 model.

It needs to be of the same version, as stated in our documentation:

Hello Joe,

My apologies, my first reply addressed model export/import (moving a model definition between repositories), which now that I re-read your initial message, may not be your request.

If I summarize what you're describing, this is more regarding refreshing a Data Hub schema's data from PROD into DEV.

Which is a separate process, so let me correct my answer.

What "refreshing a data location" actually means

This guide details the supported way to refresh a non-prod data location with PROD data.

As you'll see, this is a database-level schema dump/restore of the data location schema and not an xDM model export/import (and never the repository).

The compatibility requirement stated there is that the physical tables be compatible (same columns, same data types) between the source and target model editions, not necesarily the xDM model version numbers (even if this would be much simpler and safe).

Why your specific case still needs caution

That said, there's a factor beyond model compatibility here: your PROD environment is on xDM 2024.1.1, while DEV is on 2025.1.11. That's a major/minor platform version gap, not just a model edition gap.

Per our release notes, going from 2024.1.x to 2025.1.x involves internal data location schema changes (data location upgrades are required for major/minor version changes, not for patches).

This means the engine-level structure of a data location under 2024.1.1 is not the same as under 2025.1.11.

If the schema dump/restore replaced the physical tables in your DEV data location with a copy taken from the 2024.1.1 PROD data location, that DEV location's underlying tables may now reflect the older 2024.1.1 internal structure, while the DEV repository and xDM instance still expect the 2025.1.11 structure.

This is a genuine mismatch risk, separate from the model-version question, and is not something xDM will necessarily surface immediately, but it could still cause data load or integration job failures.

Recommendation

Given this, I'd recommend the more conservative of the two options you proposed:

1. Put the affected data location on hold and avoid running loads or deployments against it in its current state.
2. Wait until PROD is upgraded to 2025.1.11 (as you already have planned within the next two weeks), then re-run the refresh so that source and target are on the same xDM platform version, this aligns with how the supported refresh procedure is meant to be used.

I'd avoid trying to "upgrade" the data location in place right now, since there's no supported procedure for reconciling a data location whose physical schema was just overwritten by an older-version copy.

Reverting or holding is the safer path until versions are aligned.

A note on the revert option: if you do decide to revert the DEV data location instead of holding it, that would involve restoring it from a backup taken before the refresh.

This is only appropriate if a pre-refresh backup of that specific DEV schema exists.

Please confirm that before attempting it, since restoring without a valid backup would mean data loss rather than a clean revert.

Hello Joe,

Thank you for updating me on the situation.

This is indeed the safest way to go.

Good luck then!