In today’s day and age, understanding the needs of the companies we work with is a top priority, as it should be for any company. After working with thousands of clients at Sikich over the years, we’ve developed best practices and common solutions to challenges that can potentially occur with ERP implementations. We developed one implementation approach in particular with best practices for upgrading Dynamics GP to Dynamics 365 Business Central (BC), HEADSTART.
The HeadSTART implementation approach for GP to BC
HEADSTART is essentially a quicker way to get into that BC from GP. We can do ERP implementations in six to eight weeks from start to finish. It’s also less costly. We can do it for a fixed fee, or if there are additional things that need to be included, maybe some integrations or customizations. If a client does request customizations, we’d explain that the scope may extend past eight weeks.
To start, we set up BC very similarly to how the company already has GP set up. We take all the data that is in GP, including configurations, and we translate this data to function in the BC world. Now we’ve got a great starting point.
BC training with that GP data
With that familiar data, we can more easily train your team to understand Business Central. Then, once everyone has been trained on BC, they have the opportunity to make all of the changes they would have previously done.
With this method, clients are taking ownership of the system and making those changes after the fact. What we have in the end is a quicker turnaround, less time to train because the data’s more familiar, and less costly because it’s a quick implementation.
We’ve had a lot of success with this, with our GP to BC clients. It’s really that new wave approach to making the changes in your system after you’ve learned how it’s going to operate and taking that ownership on yourself.
When to use Microsoft’s data migration tool to move from GP to BC
Microsoft offers a data migration tool, which is good for users that are on GP 2016 or higher. Since Microsoft owns the tool, users can’t customize it for their individual needs. In addition, there are some things in BC and GP that are different. For instance, if you have inventory and item numbers, BC will only allow you to have a 20-character item number, where GP allows a 30-character item number.
In instances like this, we need to talk with our clients and explain the differences along the way so that we can make the decision. If we’d still like to use the data migration tool, then we might have to make some changes in GP beforehand. The nice thing about the data migration tool is that it brings over some history, but it does take a little bit to run it.
Some folks definitely do want to make changes along the way. This is where we need to have conversations with the client to ask, “Should we use this data migration tool, or should we configure your system still out-of-the-box settings in BC?”. The difference with the configuration process is that it’s based on the client’s GP settings, but we go through the configuration process manually instead of running the data migration tool.
GP to BC approaches for larger, more complex clients or those that want major customizations
We absolutely run a standard ERP implementation methodology from start to finish, meaning that we’re taking the time to do the business process review, understand how you want the system to run today, five years from now, and really take the time to step through that solution architecting phase. We provide you with full documentation so that you have the approval to say, “Yes, this is how I want my system fully configured. These are the aspects that are important to me.” You’ve ticked all those boxes, and we have that approval step before we actually go in and configure your system.
The end goal is to make sure that we’re getting you into BC, you’re comfortable, you’re trained, you’re taking ownership of your system at the end of the day, and that you’re happy with our services and the product.
Handling integrations or customizations
Sikich has its own development team. Therefore, when it comes to complex scheduled integrations, we might enlist our own development team to do those custom APIs for us. We’ll do the same thing if we need customization within the system.
In the world of Microsoft, there are endless options for plug-and-play apps. There might be something that we can pull from the app stores, which might be the resolution.
It’s really understanding the clients’ needs, whether they are going with the HEADSTART approach or whether they’re going with the full implementation approach so that we can provide the options and then choose the best model for getting from GP over into the BC world.
Keeping transactions from GP to BC
We can absolutely keep transactions from GP to Business Central. With the data migration tool, we will have a full transaction list, and we will put it in all of our documentation of what is going to transfer from GP over to BC. There are some things that are going to transfer and be in the standard BC tables, and then there’s also information that’s going to be in separate, new tables that basically say, “It’s the GP data.”
Even if you aren’t going to use the data migration tool approach, there are ways to get your data into the system. We do it all the time.
We also don’t want to bring in too much. So, when we think through what data should be in your system, we want to make sure that we’re bringing in what’s going to be useful and not just taking up space in your new system.
Partner should have knowledge of both systems
Regardless of whatever approach you use when implementing BC from GP, it’s key for your Microsoft partner to have expertise in both platforms. Many of our BC team members have a GP background.
Ready to take that next step to start your GP to BC ERP implementation, or even discuss how the HEADSTART approach may be best for your organization? Please contact our GP to BC experts at any time!
