Migrations – Why do they fail? (12 Worst Practices)

TSG has had some interesting conversations with various client prospects recently who were interested in TSG’s best practices for migrations.  While you can find a lot of references here to migration best practices (One Step vs Two, File Formats Lessons, Migrating 11 Billion Documents) , we thought for this post we would be slightly more aggressive and pass along some of the common worst practices we have seen from clients we have approached after the fact who have struggled or even failed with their migrations along with our best practices.

Migration Worst Practice #1 – Sold with an “Easy Button”

Whether it be software or a services company, too often we see clients that have bought into a sales pitch that the migration will be easy.  As we documented back in 2018, there will never be an easy button for migrations.  In the article, we mentioned 10 reasons migrations are often more difficult than they are pitched or sold to be, including:

• Finding a Compelling Reason to Move
• User Requirements and User Acceptance
• Migration Exceptions and Bad Data
• Integrations and Data Lookups
• Migration Resources
• Migration Content Updates/Changes
• Change Management for New System
• Migration AND Testing
• Differences in ECM Capabilities
• Audit Trail and Compliance

Migrations that are oversold as easy will struggle with expectations, budget, timeline, and resource constraints and will most likely result in overages, frustration, and potentially a failed migration.

• Migration Worst Practice – Oversimplifying the migration effort based on sales input
• Migration Best Practice – Assume that migration will be difficult until proved otherwise.  Focus on migration POC’s, testing, and proving how easy/difficult the migration will be.

Migration Worst Practice #2 – Inexperienced Internal or External Resources

Oftentimes we see clients leverage existing resources or internal global SI resources that are already onsite to perform the migration activities.  Too often these resources can struggle with the migration because of:

• Lack of experience with migrations
• Lack of experience with source or target content repository
• Lack of experience with migration software
• Lake of desire to learn all of the above because once the migration is over, the knowledge is no longer needed

As consultants, we have a tough time saying “your people aren’t good enough” to clients. Often their internal resources have considerable technical strengths (not always) but lack the experience and focus (they typically have 40+ hours of other stuff besides migrations to do).  As we have advised in the past, migrations are easily outsourced because once the migration is over, it is acceptable to have the knowledge walk off the project. 

• Migration Worst Practice – Staffing the migration effort with internal resources or other on-site resources that lack migration experience and have other commitments.
• Migration Best Practice – Staff migration effort with resources that are experienced with both the migration utility and the source and target systems.

Migration Worst Practice #3 – Big Bang

While looking to move off an old system, too often clients take a “Big Bang” approach where they will move all of the following in one fell swoop:

• All the content
• All the users, including training on the new system
• All the integrations

As documented in our post in 2019 about reducing the stress, cost and risk of migrations, big bang migrations have several drawbacks, including:

• Sizable migration effort – For large, multi-million (or even billion) document migrations, the timing of the migration might span over weeks if not months, given the movement of content and meta-data from the old system to the new system and potential transformations of content and metadata required.  The timing of moving users from the old system to the new one doesn’t easily fall into a simple weekend black out window.
• Migrating the integrations – For one legacy client, the old system had 60 different integrations to store or retrieve content from the old system.  All of these integrations would have to be moved and tested to the new environment.
• Iterative Piloting and Gradual Rollout – With a big bang migration approach, it is extremely difficult to pilot the new system with a small group as the movement is for all users. Piloting typically can reduce the risk and allow for improving the user experience before a system is rolled out to the masses.
• Gradual Performance Tuning – System Stabilization – Performance tuning and volume testing large, complex ECM applications is extremely difficult, as simulating user activity is often hard to predict.  With a big bang approach, the risk of performance or stability issues are huge, as oftentimes the users put a huge load on portions of the system on Day 1 without the ability to gradually improve the stability and performance over time with smaller user groups and access.

As pointed out in the article, TSG will recommend Delta, Gradual, Hybrid, and Rolling Migrations based on the use case.

• Migration Worst Practice – Planning for a “Big Bang” migration with all content, users, and integrations moving in mass to the new system.
• Migration Best Practice – Planning for a Delta, Gradual, Hybrid, or Rolling Migration based on requirements and other factors of the migration.

Migration Worst Practice #4 – Assuming Clean Data

Too often clients will assume that their data is clean and not build contingency into the migration plan for data clean-up or for addressing issues associated with the old system.  TSG has often seen:

• Bad File Pointers – content missing in source system
• Duplicate Data
• Corrupt Content
• Invalid File Names
• Missing Metadata
• Unknown File Formats

The above, along with a host of other unknown issues, could stall or substantially slow down any migration.  In a typical large migration (millions of documents), it is very difficult to identify all of the potential error conditions without somehow testing or scanning the repository before the full production migration.

• Migration Worst Practice – Assuming the data in the old system is clean and can be easily translated to the new system.
• Migration Best Practice – Assume that there are issues with the data in the old system.  Attempt to perform tests on large sample sets or practice migration runs to address data clean-up issues.

Migration Worst Practice #5 – Oversimplifying Old System Capabilities will Fit New System

We frequently see clients, particularly those heavily invested in a new system, make the assumption that the new system can do everything the old system can do with a few tweaks or additions.  For legacy ECM systems where functionality and users have adjusted and evolved their business process based on customization or a bloatware legacy interface with tons of functionality, it can be difficult to satisfy everything available in the old system.

During migration, as production users are added to the new system, we will see users bring up “new requirements” based on how they used the old system, slowing down the acceptance of the new system and possibly delaying the migration.  TSG typically recommends a couple of different ways to make sure functionality is available, or at a minimal addressed, in the new system including:

• Conduct deep focus groups and interviews to fully understand the old system and educate the users on capabilities in the new system.
• Propose running parallel systems with rolling or delta migrations in a pilot mode to allow for comparisons with real data and users to uncover additional requirements.
• Work with users on capabilities that should not be included in the new system based on work-arounds or other business methods that are more efficient.
• Have an efficient SWAT type development team that can add capabilities quickly when they are identified.

Core to the success of the system is engagement with the users through the process.

• Migration Worst Practice – Assuming that the new system will offer similar capabilities without a deep dive into the specific user scenarios.
•  Migration Best Practice – Involve users throughout the process in POC, pilot and other real-world scenarios to shake out all requirements and their effect on the migration.

Migration Worst Practice #6 – Assuming Ideal Performance During a Migration

Regardless of the amount of testing, issues will arise during migration.  In our numerous migrations, we have seen:

• Network issues slow down the migration
• Database issues slow down or crash the migration
• Data issues slow down or delay the migration

It is important to understand that despite volume testing, given large amounts of documents and other scenarios, projects should plan some contingency and risk mitigation.  See our related post on migrating to Documentum SaaS where we moved a client to the OpenText cloud and struggled with database performance issues, but had no access to the database.

Performing benchmark migrations is a critical step in migration planning. It not only provides an estimate of how quickly the production migration will run, but also gives an opportunity to identify and address bottlenecks that could dramatically slow down a migration at scale (missing database index, too many files in one folder, under-powered hardware in the source or target system, etc.). It’s important that the migration team have the agility to address and bottlenecks as they arise.

• Migration Worst Practice – Assuming that the migration will run smoothly at the tested speed.
• Migration Best Practice – Preparing a risk mitigation plan that takes issues into account and builds in fallback and contingency plans.

Migration Worst Practice #7 – Assuming Sample Data/Documents and Test Environment will be Identical to Production

Test data and test environments, particularly for large migrations, are often difficult to procure at scale to adequately test a migration.  Similar to the previous worst practice noted about assuming ideal performance, assuming that test data and environments can be easily procured and and are identical to production is another bad assumption made by many migration teams.

As much as possible, TSG encourages clients to perform test or “dry-run” migrations from the production environment, or an exact clone of the production environment, so that migration issues can be identified and addressed before the production migration. Similarly, the more that the test environment can be sized the same as production, the more accurately migration timing estimates will be, leading to a much smoother production migration.

• Migration Worst Practice – Assuming that sample data/documents and environments will be the same as production, and that test content will behave identical to production data.
• Migration Best Practice – If possible, performing a migration of production data into the test environment, as well as preparing a risk mitigation plan that takes issues into account and builds in fallback and contingency plans.

Migration Worst Practice #8 – Migrating All Business and Departments at the Same Time

Sometimes IT resources will get focused on “retiring the old system ASAP”.  As presented above in regards to user involvement, successful migrations focus on migrating groups of documents/users to build success in the new system rather than a “move everything” approach. TSG typically recommends a gradual or rolling migration to move users and documents in a controlled way to get the benefits of the new system without the big bang mentioned earlier. 

• Migration Worst Practice – Migrate everything ASAP rather than by department and document types.
• Migration Best Practice – Migrate by business, document type or rolling migration to gradually move users and content from the old system to minimize risk of the migration as well as lack of user adoption.

Migration Worst Practice #9 – Migration with No Business Benefit (Platform Migration)

TSG has seen multiple IT-led initiatives where the focus was on just moving the back-end of the repository to the new system without any noticeable change for users. This is often part of an IT improvement, cloud initiative, or other IT-led effort.  With an ever increasing need for business benefits to justify IT efforts, TSG would recommend looking for new or updated business benefits rather than only a platform change that will likely not justify the effort and could result in failure if issues with the migration or the new platform arise.

• Migration Worst Practice – Migrating without business benefits for platform migration.
• Migration Best Practice – Building both IT and business benefits into the business case to justify the new system and migration.

Migration Worst Practice #10 – Assuming Cloud will be Easier than On-Premise

While TSG has had considerable success in moving clients to the cloud, anything new will add complexity to the migration.  While the cloud does make some tasks easier, such spinning up new servers and databases and procuring storage, other dependencies can often be overlooked. Some of the cloud issues we have seen include:

• Challenges in getting all of the documents/data to the cloud
• Lack of internal knowledge of cloud architecture
• Lack of maturity of devops, CI/CD, monitoring, and backup/recovery practices in the cloud compared to on-premise
• Ensuring that the new cloud system is secured

Cloud components should be understood and a plan constructed to take these differences in mind.

• Migration Worst Practice – Assuming that the cloud will make things easy
• Migration Best Practice – Accepting that a migration to the cloud will be different than on-premise and planning accordingly.

Migration Worst Practice #11 – Not Involving Business Throughout the Process

System go-live is not the time to discover the migrated content is either incorrect or not displayed in a way relevant or usable to the end user. For that reason, TSG recommends including at least one key business user in validating the migration development and test efforts. It’s not uncommon for a source or a target system to have two very similar sounding metadata fields. For an IT professional, mapping these attributes may be an educated guess, but a business user would likely identify the difference immediately.

For a migration to be successful, the interface needs to show the information relevant to the business user in context. Just because the data was migrated to the new system doesn’t mean it is searchable or displayed in a useful manor. We have found it critical for success to get feedback from the business as early as possible in the project so that the end product is primed for success.

• Migration Worst Practice – Blindly following requirements and not involving the business until go-live.
• Migration Best Practice – Ensure that the business is involved with the project through requirements gathering data validation, and system testing.

Migration Worst Practice #12 – Export and Import Performed by Separate Teams/Tools

We are often times brought into migrations that have already been attempted once before, and typically the approach that was used (and failed) was to use the “export” tool provided by the legacy system being migrated out of, and cobble that together with the vendor provided “import” tool for the new system in a “two step” migration. As detailed in a past post on two step migrations, there are numerous reasons this approach should be avoided including:

• Issue resolution responsibility between the two different processes
• Inability to consistently repeat the process for ongoing migration needs
• Inability to quickly address and retry documents/data that failed to migrate correctly in one or both of the migrations
• Inability to provide accurate counts of documents migrated/failed for final decommissioning reports of the legacy system

When things go wrong with either side of the two step migration, finger pointing and ownership questions can erode the confidence in the ability to quickly resolve issues as it typically boils down to the question of who should fix the issue, the export team/tool or the import team/tool.

• Migration Worst Practice – Attempting to export and import using a two step migration
• Migration Best Practice – Leverage a tool that connects to the source and target systems to migrate in one step

Summary

As we have said multiple times in this forum, we don’t see migrations getting easier.  Smart clients will avoid the worst practices that include:

• Oversimplifying the migration effort based on sales input
• Staffing the migration effort with internal resources or other on-site resources that lack migration experience and have other commitments.
• Planning for a “Big Bang” migration with all content, people and integrations moving in mass to the new system.
• Assuming the data in the old system is clean and can be easily translated to the new system
• Assuming that the new system will offer similar capabilities without deep diving into the specific user scenarios.
• Assuming ideal performance during a migration
• Assuming that sample Data/Documents and environments will be the same as production
• Migrate everything ASAP rather than by department and document types.
• Migrating without business benefits for platform migration
• Assuming that the cloud will make things easy
• Not Involving Business Throughout the Process
• Export and Import are separate teams

---

Let us know your thoughts below