Secrets to a Smooth System Migration: A Step-by-Step Guide for All Technology Owners, Operators and Overseers
Over the last few years, most technology projects initiated by enterprises have been centered on system migrations. Specifically, operating system (OS) migrations. Several main legacy platforms have reached end of life, leaving edge devices without support from OS providers. In turn, newer platforms have risen to take their place. These migrations have come in all sizes and scales of manageability. And for better or worse – I prefer better – most of the migrations I have been involved in have been on the larger side. That’s the beauty of a routine – and well-planned – technology refresh. It’s usually better for all parties involved for migrations to be as expedited and all-encompassing as possible, rather than migrating a trial site and letting it breathe.
In completing so many migrations with customers over the last few years, my team and I were able to document and share key learnings so colleagues, partners, and customers could achieve the best possible outcomes with the least friction along the way.
There were some common denominators that stood out with the projects that truly excelled:
- Putting the work in on the front end and saving headaches on the backend.
- Catching issues before they cause crises.
- Setting realistic expectations and keeping as close as possible to pre-defined success criteria.
The steps below helped point us to these success criteria and are nothing unique to OS migration projects – or any technology system migration for that matter. But they can easily be replicated in most projects and should be accepted as best practice, whether you’re a project lead for your organization or the third-party integrator brought in to work alongside the project lead.
Step One: Insert yourself as the advisor as much as possible. Every technology project needs a strong voice guiding the process. This line could blur between advisor, project lead and task manager at times but lean into the advisor role. The rest will fall in place. Soak in the end-users’ needs and challenges and organizational drivers for the migration. They’ll often be one in the same and your north star for the duration of the migration.
Step Two: Do your due diligence so you can make the right technology decisions – or guide your team to make the right decisions. In most migration projects, there’ll be an option of platforms to which you can migrate. In OS migrations, for example, Android™ isn’t technically the only option for legacy Windows® Mobile and CE mobility platform users, even though it typically performs better in complex, multi-component enterprise solutions. So, remember the platform is the critical part of your next gen solution, as it will act as the backbone for all the other technology components to connect. Educate yourself on possible platforms, line them up against your end-user’s migration drivers, and run through the pros/cons of each with your end user. If there was a struggle to land in the advisor role for the project, this will assist and drive comfort with the end-user that you have their best interest in mind.
Step Three: Trust but verify. Once you and the team have a good idea of which platform you will move forward with, it’s time to confirm compatibility with all components that may need to connect with the new platform in some capacity. This is typically a pretty short list, even if you’re thinking about the longer-term roadmap, and can usually be done with a formal “request for information” (RFI) to component providers or informally through meetings with their solution engineers. This will be time to check component feature changes between platforms, platform version strategies and overall fit for the end-users’ needs. I’m a firm believer that there’s no true “out of the box” component that’s ready for any end-user. Some development work should be expected here.
Step Four: Verify again (from a comprehensive vantage point). By now, there should be some confidence in the preferred platform and which components will fill out the rest of the solution. Ideally, the preferred components will be limited in quantity and chosen on their viability for the overall solution – not based on a unique feature or cost consideration. But it’s important to confirm they can indeed deliver. Remember, up until this point, components have only been individually evaluated or considered in the context of select integration points. You need to make sure all the pieces will come together as needed and be compatible with each other. Commonly referred to as a “conference room pilot,” this type of discovery session will keep all component stakeholders honest about their component’s capabilities and help you catch any surprises that could need to be addressed before you get to the full-scale implementation and realize you made a wrong turn at this fork in the road. What you do – or do not do – at this point will have a large impact on outcomes.
Step Five: Get buy in and sign off from all stakeholders. Once an all-encompassing evaluation is done with all possible components, the solution is mostly formed, and all stakeholders should have a solid understanding of the work needed to get to the finish line. This is the point where all stakeholders need to finalize terms, implementation strategies, and rollout plans. It’s critical here to stay grounded in reality. Setting unachievable deadlines and success criteria will only add pressure and hard talks to the mix, which are always a hit to project productivity. Working the overall plan into manageable phases never hurts.
Steps Six and Seven: Communicate. Test. (Repeat.) These are the two most important steps to success. That doesn’t mean you can disregard everything I’ve said to this point. If you skip any of the above, mistakes and regret are bound to transpire. It’s just vital that all parties involved in the project are consistently aligned.
You should be having open, frequent dialogues as early as possible, throughout the rollout, and even after the solution is live – especially with end-users and those who will be responsible for maintaining the solution. Early and frequent inclusion will give them a feeling of ownership and ease the rollout once the solution’s ready to go-live. Their feedback will ensure any issue is found quickly and addressed even quicker. Issues found late and only known to a portion of the stakeholders tend to grow fast, affect unknowing stakeholders’ components and turn into serious productivity sinks. For example, you don’t want to find an issue once you begin your rollout, only to hear that a couple super users involved your initial pilot had long been aware of the issue and already crafted a system workaround for it. (True story!)
Component and overall solution testing should follow the same rules: start testing early and often. Robust testing starting in the evaluation stages, sustained throughout the implementation and conducted once the solution is live can catch issues before they hit the field.
My Best Advice: Proceed with Both Caution and Confidence
These simple steps can take time to manifest but are the difference between a successful project and one that needs continued hand holding for the life of the solution. Trust me, I know. The system migration that followed these steps closest is one I still dream about to this day. It was a consumer packaged goods (CPG) distributor migrating one of its divisions with 6,000 routes from a legacy route accounting solution to a new platform. There were significantly more change variables than the CPG industry is accustomed to. This customer followed the above steps to the letter: had a thorough evaluation, detailed implementation, full-fleet rollout of ~10 months and – most importantly – minimal solution support since! In fact, rather than be onsite for the first site’s “go-live,” the project leads were standing with me in a tradeshow booth. Not hearing a peep from their on-site team and exuding the cool confidence of expecting nothing less. I was very grateful to all parties involved in that migration and would work with them on other projects with them in a heartbeat! In fact, I did. (There were several more projects that soon followed, all just as successful.)
Migrations that veer away from these steps…well, there’s many.
In the haste of things, it’s very easy to pick a platform without researching and considering all industry leading components. With just one wrong first decision, you could find yourself on a hamster wheel, cycling through one component after another, hoping the next selection will be better. And once you get on that wheel, it can be hard to get off. Multiple small fires and hidden issues will start growing until they are almost all too big to fix, resulting in a lot of wasted time and unnecessary stress. Believe me, I’ve been called in to help customers who spent over a year and a half trying to rollout a small number of devices, because one issue after another cropped up as they tried to implement different solutions to fix other ones. Some are still dealing with issues years later.
If you ever want to hear some of those war stories, just hit me up on LinkedIn (and make sure you have hours to spare)! But know I would far rather talk about the best practices you can apply to one day have your success story featured here. So, don’t hesitate to reach out. My team and I would be happy to walk you through these steps in the context of your specific business goals and migration ambitions.
###
Related Read:
Paul Hilton
Paul Hilton is the Food & Beverage Industry Lead, responsible for ensuring that Zebra is aligned to the needs and challenges facing groups producing and distributing perishable goods. Paul has more than a decade of experience within the food and beverage industry, assisting groups with streamlining their manufacturing and supply chain operations, and transitioning legacy solutions.
Previously, he served as account executive, where he advised on last mile delivery and service challenges.
