A primary success metric when users are involved in a transformation project such as a tenant migration is how users perceive the project. Our aim here is for users to perceive it well, resulting in greater use and adoption of the new environment. A bad result here looks terrible on the project team and IT and will have a lasting impact on user experience and productivity.

No migration is seamless or perfect, but users will still perceive the change favourably if there is a clear communication and engagement strategy.

The first step is to identify stakeholders and assign their migration roles. We do this because the business stakeholders usually know their environment and processes better than IT. Some projects we are engaged in show resistance to involving users in this process, leading to cutover issues that take a long time to remediate. At a minimum, we recommend the following stakeholders are identified for most projects:

• End-user/Tester – to ensure we have the correct people testing their systems
• Business Unit Manager – responsible for identifying and managing their unit
• Champions – Responsible for owning user experience and adoption
• Business Process Owner – responsible for identifying the business process they own and then testing them in the new environment

These stakeholders are generally responsible for a part of the migration experience and should be taken on the journey from the start for the best possible outcome. Identification of these stakeholders should be the responsibility of management within the organization; after all, they are the ones who want their users to keep working efficiently during this process.

Once the stakeholders are identified, these are the things you need help with:

• Communicating that the project is happening and where/ how their assistance is required
• Identification of the processes, integrations and other bits you need to test after the migration
• Testing and validation activities

Go slow to go fast! This is our motto when it comes to migrations. For a good reason as well – here are two examples of a wrong approach and the right one:

1. We joined a migration that had already progressed past the planning phase, running essentially ad-hoc groups of users’ workloads without stakeholder identification. In the end, we experienced a prolonged migration process rife with indecision and risks. For example, the client took five weeks to decide and purchase a tool near the end of the first phase of the migration, and so it ended up taking months longer than expected for this reason.
2. We ran a planning engagement for a project following our methodology, which produced a migration blueprint estimating a three-month project duration. We then identified stakeholders, brought them into the project – reducing risk and accelerating timelines.

Why is communication so important in T2T projects? Here are our top four reasons:

1. User engagement – If you want a good user experience, then you must engage users in the process; this is a no brainer!
2. Identification of things you do not know about – end-users know their jobs better than you, so by making assumptions, it will likely backfire. Engage them, figure out what they use, and how!
3. Testing – again, users know their environment and what needs to work. IT can look and say, “that looks fine”, but inevitably something will break which hasn’t been considered unless users test it.
4. Feedback – is essential and helps the project improve. You want feedback for both good and evil; silence is where the problems start to arise!

Now our stakeholders have been identified and categorized, what should you communicate? It is just what is happening for most users and when tasks to complete, and what to look out for so they are engaged and aware.  The requirements start from the beginning and end after cutover for business process owners or identified testers.  The following are examples of ways you can communicate effectively:

• Surveys to identify what users do
• Workshops or interviews with business unit managers to identify critical systems or processes
• Testing guidelines or plans
• Changes, migration times and other general communications
• Feedback forms

The above may seem like a lot, but most environments have been established and used for some time and have operations which can’t be easily lifted and shifted. So, identify and test thoroughly to prevent any negative impact on your user experience.

Have you defined risk tolerance? Did you communicate with the right people? Are you sure you have planned sufficiently? Managing user experience should be easy from here

As always, if you need assistance with a Tenant to Tenant migration, please reach out to see where we can help you.

Follow Plow Networks: Twitter, LinkedIn, Facebook, and Instagram

The information is brought to you by our certified partner, Insentra.