Every business makes a system migration decision. The frequency of these decisions has increased significantly, as the improvements to technology are delivered more quickly. Unfortunately, migrations tend to take much longer than everyone wants or thinks. My experience has shown that the following considerations need to be understood and carefully managed to have a successful migration.
- Why are you migrating?
- Are there hard dates that apply to the project?
- How broad is the data or processes you are migrating?
- How are you controlling the transformation (of data or processes)?
- How and when are you validating?
- What are the plans for cutover, training and UAT?
Why are you migrating?
There are always multiple reasons for making a migration decision. Some may be technical like obsolete hardware or degrading software. Other times it may come as result of cost. Regardless of the reason, it is imperative that you also provide business users a reason for the move. This migration will be an inconvenience and they will need to adapt to a new system. You should not do anything that impedes their ability to advocate for the new system. It helps if you can showcase some quick wins by delivering some new business value.
Are there any hard dates that apply to the project?
While this might seem like an obvious question to be asking, it makes a huge difference in project planning. With legacy applications, it is very difficult to plan for every unknown. There tend to be layers of configurations, application upgrades, and varying techniques for implementation and execution (read “spaghetti code”). While all projects should have timelines and deadlines, many times you can build a buffer window in to account for the uncertainty. Ideally, you are planning for future use not just blindly implementing a new system the way it was before. Now is the time to proceed with a fresh set of eyes while still maintaining the insights garnered previously.
How broad is the data or processes you are migrating?
This question tends to raise interesting responses. For all practical purposes, most business users use a finite set of data (year-to-day, 1, 2, 5 years). However, if you pointedly ask a business user what the minimum amount of data they could live with, inevitably the answer will be all of it. This generally conflicts with how much IT really wants to store or with practical wisdom of data management. Over time, the system has changed, therefore the underlying data has changed.There is a real possibility that early data is of questionable quality and will add no real value for ongoing business use. It may also add some complexities to the implementation process as well. This is also wisdom for most process migrations. Unless you can demonstrate business value of leveraging less data or fewer processes, business users may be wary of the new system.
How are you controlling the transformation?
As mentioned previously, it is recommended to look at a migration from a fresh perspective. Often, this will introduce some requirements to transform the data or process. The application of business rules or assumptions must be fully documented. Additionally, any resultant changes in data or processes identified during the validation stage should be related to those business rules. Make sure the business users embrace the these decisions. If they do not, it will be challenging to get them to engage later in the implementation, or post implementation where critical eyes are determining whether this project is a success.
How and when are you validating?
There are quite a few different steps in the validation process that must occur in a migration. First, there are the basics of making sure your system is implemented and configured to your requirements. More critical is validating that the business use cases return the expected results. Your implementation team should be validating at each step of the way to ensure that issues are quickly identified and resolved.
Validation must occur using methods or interfaces the business users will use. There are general concerns and uncertainty about new systems and being able to provide validated results using agreed upon business processes can go a long way to appease them. Some anomalies are legitimate and they must be fully explained and documented. All sets of tests need to be documented, reviewed during training and UAT and made available to stakeholders in formal documentation or on an internal intranet.
What are the plans for cutover, training and UAT?
Business users need to feel comfortable fulfilling their most basic business needs. If there are nuances or differences on how to accomplish these or in basic assumptions around them, these should be highlighted accordingly. Next, it is helpful for the business users to learn skills that can deliver new business value fairly quickly post-implementation. The goals are to reassure business users that they can still deliver the value they did with the old system, but also that they have new functionality that allows them to deliver new value quickly. This may be as simple as making old value propositions better, faster or more robust.
During this time, the implementation team must quickly respond to questions, issues or concerns. These are the most basic interactions the business users are going to have and will start laying the groundwork for the trust that is required for an implementation to be considered successful. The ultimate goal is for the initial users to fully engage and become advocates across the organization. If these users fulfilled that role with the old system, it will be detrimental to success if that is lost. If these users were not advocates before, it is imperative to win them over.