AnsweredAssumed Answered

Using XOG for data migration - Upgrade/New Implementation

Question asked by Scott Derderian on May 13, 2013
Latest reply on May 14, 2013 by Scott Derderian
We are currently in the planning stages of an upgrade from version 12.1 to 13.2

As a part of this we are looking at potentially performing some data cleanup.

Rather than perform a like-for-like upgrade of our current implementation, we are looking to potentially start out with a new installation, then via XOG, only bring over those projects and resources that we wish to bring over into the new implementation, based on business rules determined by the business.

We are also planning on going through all of our custom attributes, only bringing over those attributes we wish to keep. We are looking to go to as close to an “out-of-the-box” implementation as possible.

Post Upgrade, we will keep a version of the “as-is” implementation (from a database perspective) available for future reference.

Has anyone out there every performed something similar, either in conjunction with an upgrade, or just to “start over” with a new implementation of their existing implementation?

If so, please share your experiences. I am particularly interested in any challenges you met along the way, in addition to any documentation you may have (or can direct me to) pertaining to best practices, order of XOG script execution (both in-bound and out-bound) and any other pearls of wisdom you wish to share.

Thank you.