Transferring data and configurations between environments might not be as simple as it seems if instances of D365 Marketing are involved.
Although Microsoft's official documentation for D365 Marketing App states that Configuration Migration tool can "move validated journeys, emails, and other content from a sandbox to a production environment", the "other content" piece may easily fool implementers into thinking that cotent like marketing pages and images can be moved with ease, which is often not the case.
In this article, I am going to illustrate why creating all pre-approved content in a sandbox environment with D365 Marketing app might introduce a lot of issues for deployment to production.
Let's start with one of the simplest issues, which just happens to be one of the easier-to-resolve issues.
If you have a live marketing page in the test instance of D365 Marketing app, it would be hosted on the Powerapps Portal installed with marketing application. Looking at the full page URL of this marketing page, you would notice the development related domain:
Once this page has been migrated to another environment with D365 Marketing app, the full page URL would still be the same - pointing to the Powerapps Portal of the source environment. This happens because the Configuration Migration tool simply copies all data to the target environment.
This is an issue because the page URL would clearly indicate that the page is in a development environment and this page would cease to exist once sandbox Powerapps Portal is disposed of. There is a simple resolution to the issue: stop this live marketing page and go live again (go live directly if page is in "Draft" mode), the system will do a self-correction and publish this marketing page under the Powerapps Portal of the new environment.
Now you might be wondering - this does not seem like a real issue at all if I can resolve by republishing the marketing page! However, if there are hundreds of landing pages (due to localization and other considerations), this process needs to be automated on all the pages using a Power Automate Flow and there are many other aspects to be considered - for example, system performance impact.
Generally speaking, this is indeed a relatively small issue considering the minimal disruption to system operation when it is being resolved.
Onto the one of the complicated issues: image records copied over to the target environment using Configuration Migration Tool are only stored as references to images of the source environment.
An image uploaded to D365 Marketing using the user interface will be saved to a private directory (for each unique environment) of a Microsoft owned server. Once this process is complete, the image will be cached through a content delivery network and it can be served through the internet with unique URLs. This URL information is then saved with a record of "Image" table in D365.
When image records are migrated to another environment using Configuraiton Migration Tool, the URL information is simply copied over and the image records are merely referencing the URL of images in the source environment. The following picture shows a list of image record, of which the first one is created using upload while the rest are migrated from the source environment:
Again, this wouldn't be an issue until the source environment (which is usually a development environment) is disposed of. However, if that happened eventually, all marketing emails, forms and pages built using the images will show broken images as the cached images are removed from content delivery networks and server directories as a whole and they are no longer accessible through internet.
To work around this issue, you need to gather all the images uploaded to the source environment and bulk upload them into the target environment using the out-of-box image upload functionality. Doing so will publish images to a new sub-directory of content-delivery network for the target environment. Unfortunately, all images being used on marketing content such as marketing emails and marketing forms have to be re-embedded to ensure all the marketing contents are referring to the correct image URL. As you can imagine, the effort required to work around the image reference issue grows exponentially with the number of images and the number of contents referencing the images.
As of today, there isn't a streamlined and automated solution of migration marketing content between D365 Marketing instances but you may not need a migration solution most of the time.
A D365 Marketing app contains both configuration data and marketing content. Configuration data such as content settings has no difference from other D365 app's configuration data, which can be migrated between environments using Configuraiton Migration tool without any issues. However, marketing content is just like the content managed on any CMS (content-management system). If you are familiar with any CMS like WordPress or SquareSpace, you know that contents are managed in only one environment, but with different statuses - published, draft, etc. The statuses are used to separate test/development content from anything publicaly available and D365 Marketing is using the same design to manage the content lifecycle.
In my opinion, all content which should be published or likely to be published in the forseeable future can be placed in the production environment. For example, marketing emails and marketing pages can be created before production go-live and kept in the draft status. Some content may be created in a development enviornment to test customizations added to D365 Marketing app and integrations with other applications, but the solution manager should always bear in mind that content in development is disposable.
Having a solution/environment management and deloyment strategy is key to the success of a project but not everything has to be included in the solution management and deployment pipeline.
Top comments (0)