Enterprise Data Management: Migration Options
Introduction
On a few recent projects, I’ve been asked about the best practices and available options with migrating EDM applications across environments, whether it be refreshing a Test environment from Production, migrating the latest updates to Production, or something in-between. I thought, what the heck, this might be a good topic for a blog so here we go.
When discussing EDM migration options, it really boils down to 3 options:
- Artifact Snapshots
- Dimensions
- Requests
Artifact Snapshots
This is the easiest, and most obvious option, with 2 common use cases:
- I’m starting a new project and need to refresh my Test environment from Production to establish a recent and up-to-date baseline
- I’m ready to go-live for the first time with EDM and need to migrate from Test to Production
The process is quite simple. In the source environment, create a new Artifact Snapshot (or use the nightly snapshot automatically created during the maintenance window) and download the snapshot to a local computer or file server. All artifacts and content will be captured in a single ZIP file. In the target environment, upload the snapshot then import it to restore the complete EDM environment. Voila! You are done.
See the screenshot below for the relevant actions on the Migration screen.
There are advantages to this approach but also some words of caution to keep in mind:
- It's Easy and Fast
- You can migrate an entire EDM environment by uploading and importing a single snapshot
- It’s Comprehensive
- The Artifact Snapshot contains everything, including the kitchen sink and the tools you forgot you had in the shed in the backyard:
- Content - nodes, hierarchies, mappings, property values
- Code - all the configuration, subscriptions, approval policies, validations, and other setups
- Security - all user/group/role assignments and permissions
- It’s Self-Service
- You can migrate the entire environment in a single ZIP file without the need for IT intervention (unless IT is the only group with the edmcs-service-administrator role).
- Caution
- Snapshots are Not Granular
- Since a snapshot includes everything, this means all applications, views, data chain objects, subscriptions, approval policies, transaction history, and request history will be replaced when you import the snapshot.
- You can exclude Group and Memberships from a snapshot but that’s about it.
- This approach is similar to doing a full DRM repository backup/restore, for you DRM’ers out there.
- Never fear, granular application-level LCM should be coming in Spring 2021! (safe harbor)
- Since a snapshot includes everything, this means all applications, views, data chain objects, subscriptions, approval policies, transaction history, and request history will be replaced when you import the snapshot.
- Snapshots are Not Granular
- Backups
- Be sure to create a fresh Artifact Snapshot backup in the target environment prior to importing the new snapshot (this applies for any type of migration really).
- User Provisioning
- Make sure the same EDM users are provisioned in both source and target environments.
- Release Levels
- Snapshots can be imported when the target release level is the same or higher release level as the source:
- Migrate 21.01 to 21.01 – yes
- Migrate 21.01 to 21.02 – yes
- Migrate 21.02 to 21.01 – maybe but not guaranteed
- Migrating from higher to lower release levels is not guaranteed to work; in some cases, when there have been relatively few enhancements between monthly releases, you can get away with it since the underlying schemas are compatible. But again, it may not work and you won’t really know until you try it.
- Why is this important? Because it can impact project go-live dates. If I plan to go-live on Feb 15, your test environment is 21.02 but your production environment is still 21.01 (until Feb 19).
- Snapshots can be imported when the target release level is the same or higher release level as the source:
- The Artifact Snapshot contains everything, including the kitchen sink and the tools you forgot you had in the shed in the backyard:
Dimensions
This option is relatively easy, albeit a bit tedious. The idea is simple; export dimensions to CSV files from the source environment and import the same CSV files into the target environment. This process would be performed on the Applications screen:
- It only impacts “content”
- This approach only impacts EDM “content”, or hierarchies, lists, members, and property values
- It will refresh the dimensions in the target environment but other configuration, security, requests, and transaction history is not affected.
- While a bit of a stretch, this approach is somewhat comparable in DRM to doing a Version backup and restore.
- It’s quick and self-service
- You can relatively quickly export and import key dimensions without the assistance of IT (depending on your EDM roles/permissions, of course)
- This can be useful when source/target environments are very similar in terms of configuration, and you just need the latest hierarchies in the target environment for testing or perhaps some “what-if” modeling.
- It can be automated
- If it’s a process you will repeat fairly often and involves several applications and dimensions, you can script it with EPM Automate or REST API calls.
Requests
The final option is not one I have used as often as the others but does come in handy in specific situations. As with the other options, the idea is simple: download the requests from the source environment and submit those same requests in the target environment. The download is performed on the Requests screen:
And then in the target environment, create and submit new requests using the downloaded files as request files.
- It’s Quick and Self-Service
- Even if the request did not originally use an Excel request load file, the request can be downloaded to a complete request file.
- This option, in my mind, is similar to using DRM transaction history to generate action scripts that are then processed in a target environment.
- It’s Specific
- A specific request or range of requests (use those handy filters on the request screen to isolate the activity you want) can be downloaded.
- For additional control and granularity, the downloaded request files could be edited prior to submitting in the target environment.
Summary
That’s it for this edition and I hope this clarifies the available options in migrating EDM applications along with practical use cases for when you might use each option. Stay tuned for more EDM blogs!
For comments, questions, or suggestions for future topics, please reach out to us at infosolutions@alithya.com. Visit our blog regularly for new posts about Cloud updates and other Oracle Cloud Services such as Planning and Budgeting, Financial Consolidation, Account Reconciliation, and Enterprise Data Management. Follow Alithya on social media for the latest information about EPM, ERP, and Analytics solutions to meet your business needs.