Microsoft Dynamics 365 Migration Guide

It’s important to understand that every Dynamics 365 migration is unique.

Two companies in the same industry might select the same Microsoft stack to address the same set of problems. Yet–despite the overlap, the same two companies can have completely different migration experiences.

In part, that’s by design. Dynamics 365 is a set of modules that you can buy as part of a plan or a la carte. That way, you have the flexibility to design an ERP system around your organization’s unique needs and processes.

But these one-of-a-kind journeys have less to do with which modules and add-ons you choose than the sheer amount of variables that come into play. Those variables include everything from custom code and third-party enhancement solutions to your goals and the maturity of your data strategy.

In this Dynamics 365 migration guide, we’ll share some best practices to help you prepare for the big move – and everything that follows.

Evaluate Your Current ERP System

Failing to address business requirements and process flows early on can undermine the entire migration. Before getting started you’ll want to:

• Document current processes. Start by taking a deep dive into your current solution. This includes all data sources, apps, integrations, processes, and data flows. What’s working well? What’s not working? Where are you running into information silos or experiencing poor alignment?

• Interview end-users. Next, you’re trying to figure out how the current system impacts the real people using it every day. Ask specific questions about what users like—or don’t–about the current system. Where are users experiencing pain points? Which processes contain too many steps or take longer than they should? What would they like to take with them when they move to the cloud?

Learn About Everything Dynamics 365 Brings to the Table Many of the new functionalities center around unification, visibility, and alignment between people, processes, and technology.

Last week we highlighted the general benefits that come when you move from an on-premises solution to the cloud. Unfortunately, companies often fail to define how processes can improve and try to recreate old processes in the new system.

Instead, consider how new functionalities address employee pain points or help your business capitalize on emerging opportunities. A few examples:

• With Power BI for Microsoft Teams and Office 365, you can streamline remote collaboration, knowledge sharing, and surface high-priority tasks. You also can use team usage data to identify opportunities to help employees be more productive. How are they spending their time? Which processes could be automated? Which workflows could be optimized?

• If you’re looking for ways to improve your supply chain management capabilities, you might look for ways to leverage IoT data inside Business Central. Think–real-time inventory counts or predictive sales forecasting that can help you manage cash flow or better optimize warehouse space.

• Or you could train employees to build new apps themselves using Microsoft’s low-code tools. As an example, Toyota North America trained employees to build apps to solve business problems using Power Apps, Power Automate, Power Virtual Agents & Power BI. They then used their creations to build a Center of Excellence for sharing knowledge/solutions with peers.

The possibilities are endless. But it’s important that every choice you make connects to a real-world scenario. Preparing a list of requirements, pain points, and business objectives and presenting them to your implementation partner allows them to help you understand all available options and plan your deployment approach.

Select a Migration Path That Aligns with Your Business

Unlocking the full potential of Dynamics 365 hinges on understanding all factors that influence the migration process.

That includes the significant differences between legacy solutions. For example, Dynamics SL and GP work differently than NAV and follow a different migration path because of those differences.

Here’s a very brief overview of those different paths:

• NAV to Business Central. Here, you’re looking at a two-tiered migration process where you’ll first migrate data from NAV to the on-prem version of Business Central, then again to BC in the cloud.

• SL & GP to Business Central. SL and GP migrations focus on bringing financial data from your on-prem system to the new, cloud-based ERP. This means you may be migrating data from other ERP solutions at the same time.

And then there are the stark differences that exist between older on-prem solutions and their cloud-based counterparts. Customizations are written in different programming languages. Databases are formatted in different ways.

The age of your legacy system is another significant factor. Older versions of, say, GP or NAV, could add an extra set of complications to the process. Many times, that means the workflows and customizations you’ve relied on for years won’t be joining you in the cloud.

The longer you’ve been using your current ERP, the longer it takes to identify, map, and clean the data you’ll be taking with you. Not to mention, untangling the various integrations and customizations that have piled up throughout the years.

Map & Clean Data

The bulk of the Dynamics 365 data integration and migration process is about prepping your data for the big move. It’s tempting to migrate all data to the new platform.

But this actually creates more problems in the long run and could derail the project altogether.

Map the Data. Data mapping allows you to determine who owns the data, who uses the data, and identify the data that’s worth taking with you.

It also allows you to determine which origin fields line up with which destination fields and get an idea of what legacy fields will look like post-migration or whether they’ll have new names.

You’ll want to create a map containing the following components:

• Data sources

• Customizations

• Configurations

• Data

• Code

• ISV solutions

• Add-ons

You’ll also need to identify what you can’t bring with you to the new system.

Clean the data. During the migration, data cleansing becomes especially important as properly cleaning and transitioning data into the new environment will facilitate better reporting.

It’s the final line of defense keeping bad data from entering the new system. You know–garbage in, garbage out. This process will help reduce the effort and expense of removing duplicate records and inaccurate/outdated information post-migration.

Verify & Test

Lack of data validation, inadequate user acceptance testing, and lack of user interest in learning the new system can cause a migration to fail.

Here are some steps you can take to ensure that doesn’t happen:

• Create test scripts. To ensure all processes align with team objectives and the big-picture plan, you must analyze them against several different scenarios. That means, you’ll need to define test cases and come up with test scripts based on the business requirements associated with different scenarios.

• Configure test environments. If you’re migrating to Business Central, you can set up a sandbox environment using Visual Studio.

• Run test scripts in the new environment. The goal here is ensuring that everything performs according to plan. Identify issues or areas for improvement and estimate what it’ll take to make those adjustments.

• Conduct CRP sessions. Conference room pilot sessions are used in project implementations to test normal use cases in the new system to identify people, processes, problems, solutions, and standard best practices.

• User Acceptance Testing (UAT). UAT combines training and testing and aims to help you determine whether the migration aligns with system requirements. Have end-users check for missing data, confirm that legacy and cloud fields match, and test workflows to ensure they’re working as planned. Users must also sign off on each test case before pushing the code to production (indicating everyone is in agreement.

• Test plug-ins & third-party integrations. You’ll want to make sure they’re both secure and compatible with the rest of the system.

Testing should be a continuous process so it’s important to validate data throughout the entire upgrade process.

Final Thoughts

As you can see, data migration is a significant undertaking with many moving pieces. While it’s not an official step in the migration process, it’s a good idea to get a very experienced, certified Microsoft partner like Micro Force involved early in the game. Especially if your current system is a barrier to achieving your organization’s strategic goals.

Hiring an experienced partner will help you make an informed decision about how you’ll approach the process, help you determine whether it makes sense to “lift and shift” without changing existing processes, or whether a full-scope implementation will better align processes with your business goals.

Teaming up with an experienced partner also allows organizations to get up and running fast. For example, if a client encounters an issue during testing, they report it to the partner and they resolve the problem. Then, once all issues are resolved, the technical team deploys the final upgrade for the go-live.

Clients save time and resources they might otherwise spend searching root causes and identifying & implementing solutions. Or worse–running damage control post-launch.

Our experts can help you navigate the Dynamics 365 migration process–every step of the way. Contact us today to learn how we can help you set the stage for a successful migration, implementation, and beyond.