Common Mistakes When Deploying Dynamics 365 Solutions

An import into the production environment is rarely spectacular. Either it runs through, or it breaks off after a few minutes with a message that only hints at the real reason. The causes repeat themselves surprisingly often.

Missing dependent solutions

The most common abort. Your solution references a table or a field that comes from another managed solution. If that solution is missing in the target environment, the import cannot finish.

The tricky part is the delay. The import runs for several minutes and then breaks off. With a large solution you quickly lose 15 to 30 minutes per attempt.

The list of required solutions is in the export of the solution itself, in the "solution.xml" under the missing dependencies ("MissingDependencies"). The version is noted there for each entry. It is exactly the list you also see when exporting in the web interface. If you check this list against the target environment beforehand, you save yourself the failed attempt.

Environment-specific values that travel along

Environment variables are meant to carry different values per environment: a SharePoint URL, an identifier, a threshold or a specific name. The definition belongs in the solution. The value does not.

In practice the value often travels along anyway, because it was set in the development environment at export time. During import it then overwrites the correct setting in the target environment. The import reports no error. It only becomes noticeable when a flow suddenly writes to the wrong SharePoint library.

Unmanaged customizations in the target environment

If someone has changed a form directly in production, that change sits as an unmanaged layer above everything you deliver as managed. Your fix arrives but has no effect.

The classic course: you deploy, check, see the old version, deploy again, with the same result. Until someone has the idea to look for the unmanaged layer.

Deletions that do not go through, or unexpectedly do

If a component is removed from the solution, it depends on the import type whether it disappears from the target environment with the next import. With the standard import of a managed solution (the upgrade) it is deleted, along with the data if it was a field. With the "Update" option and with unmanaged solutions it stays.

Both have their failure patterns. If you deliver unmanaged or choose Update, you accumulate in production over the years what was long deleted in development. Cleaning that up is then manual work. If you deliver with Upgrade, you should know before every import what disappears. Both are covered in risks in solution upgrades.

Solutions that are too large

Beyond a certain size, the import itself becomes a risk. It takes long, and if it fails in the middle, the state of the target environment is unclear.

A solution with several hundred components is not automatically too large. It becomes critical when it contains several functionally independent areas that you could deliver separately anyway. Then splitting pays off, also because of the shorter import times.

What you can check beforehand

From a solution export you can answer several of these points in advance, without touching the target environment.

• Which managed solutions must be present, and in which version?
• Does the solution contain environment variables with a shipped value?
• How many components does it contain, and are they spread across several name prefixes?
• Are there references to components that are not shipped at all?

This does not replace a test import. But it prevents the failed attempts whose cause was already known before the click on Import. A checklist version of these checks is in quality checks before deployment.