web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Model vs XPO deployment from TEST to STAGING during implementations

(0) ShareShare
ReportReport
Posted on by 747

Hey all,

How do you manage to do model deployments in 2012 when moving code from TEST to STAGING when there are multiple projects in multiple states? Eg. during a large scale implementation.

eg. Client has DEV, TEST, STAGING, and PROD environments.

Client dev exported project A and project B from DEV to TEST via XPO.

In TEST, Project A has been validated by the SME, project B has yet to be tested or had an issue.

Client wants to move project A to PROD.

So project A and B are in the same model in TEST. How do you move project A to STAGING without moving project B?

Are devs required to create a separate model for each customization they do? Even if that's true, aren't objects only assigned to one model? What if two projects modify the same object? This has always seemed crazy when there's multiple xpos touching multiple objects that frequently overlap.

Is there even any risk to doing XPO deployments to STAGING if you're doing modelstore deployments to PROD? All of the existing element IDs should stay intact and any new element IDs will not conflict with prod, unless I'm missing something?

Model deployments seem fine for ISV solutions and whatnot, but I've never been able to figure out how they fit into the standard end-user implementation and support scenarios...

*This post is locked for comments

I have the same question (0)
  • Martin Dráb Profile Picture
    239,647 Most Valuable Professional on at

    I personally refuse to call something tested if you test on an environments that contains other changes (which are not going to be released at the same time). In such situation, what you'll get in production is something else than what was tested in Test, therefore it may behave differently. If you create a new version of application by extracting just some objects, you should test the application. You would do integrating testing in an additional test environment or possibly in staging.

    You already answered yourself why it's impossible to have a new model for each work item. I think a model should represent a product, or an isolated component; it doesn't matter of how many work items, developers or releases are involved.

    .xpo imports are always risky - people import them to wrong models (which can have many consequences), don't extract changes from the source environment correctly, overwrite changes that they weren't aware of, forget that some object should be deleted (you can transfer this information via .xpo; the person releasing code must do it manually), sometimes things fails to import correctly... Because of these risks, it's wise to minimize .xpo extractions and imports. .xpo are clearly not intended for deployment; importing an .xpo is the same as having a developer writing the same code manually...

    Note that if you want to isolate development of several separate components, you can use separate branches in version control. But isolation obviously requires having more than one AX instance.

  • Mea_ Profile Picture
    60,286 on at

    Hi Kyle LeBarre,

    As Martin mentioned, if you do xpo to staging that means that you tested one thing and in production you will have something different that was not tested.

    But for some customers we have bunch of mods in TEST thats were not tested and we need to promote some bits to prod, so we are using XPO from test to Staging, then modelstore from staging to "preprod" where users do regression and then same modelstore to prod. This way is not ideal as well and requires double testing but you cannot avoid it in this case.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the April Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
CP04-islander Profile Picture

CP04-islander 34

#2
Michel ROY Profile Picture

Michel ROY 14

#3
Jagadabi Profile Picture

Jagadabi 6

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans