How Long Does a Business Central Implementation Take?

Now, where did I put my piece of string? Business Central is an ERP system aimed at small to medium sized companies. This covers a huge diversity of requirements, from wanting a straight replacement for an accounts package to utilising the full capability of what is a very powerful ERP platform.

Microsoft have previously talked about “Live in a day”. Is this possible? Technically, if you use a pre-configured templated setup. But, do you have all your data ready to import in a perfect, pre-defined template? Is your business completely standard and you’re happy with all the pre-configured documents? Have you watched all the training videos and do you possess perfect recall? So, maybe. But only if you’ve done a lot of work in advance and, if that’s the case, it didn’t take a day!

Business Central can bring huge benefits to an organisation so we believe you should take the time to be able to realise those benefits. There are several elements that help us to estimate what is and isn’t a realistic timescale. In this post, we will cover what those are before mentioning the typical length of time an implementation takes.

Where are you starting from?

One factor affecting the time required for the project would be the system that you’re moving from. Is it a full legacy ERP system or a basic accounting package and a lot of spreadsheets? This has an impact on both functionality and data migration.

Where your ERP system has undergone significant customisation, we will need to determine whether Business Central has that functionality as standard. It may be we need to customise Business Central to meet your needs. For a highly customised system, we may have to determine whether Business Central is an appropriate fit at all!

Implementation from a Dynamics product

Typically, migrations from other Dynamics products give the simplest implementation projects. Whilst Business Central’s evolution has been extraordinary, the core of the Dynamics product has existed for years within Dynamics NAV, under the same naming convention and structure. The reason this simplifies the process is it speeds up data migration. If it’s clear which fields in the old system map to the new system, it’s simple to pass data across. Additionally, if users are familiar with the basic concepts from NAV, they will recognise those same concepts in Business Central.

Implementation from a product outside of the Dynamics family

If you’re taking data from a system which isn’t a part of the Dynamics family, there may not be corresponding tables or fields in Business Central. In that case, we’d need to decide whether customisation of the system would be necessary to incorporate them. Where Business Central has fields which aren’t in your old system, they may need to be populated manually or via an import. This of course depends on their relevance to your processes.

Where are you going?

Do you have a clear vision of what the new system should give you? Business Central is a very different beast to ERP systems of 20 or even 10 years ago. Time should be allocated to understanding what the system is capable of and what that can do for your business. A new ERP project might become a business process re-engineering project.

Understanding which data should be migrated

One task for the customers is simply to work out what they need. It’s not unusual for archaic, unused data to be on an ERP system. A new implementation is an ideal time to really consider what data is important to the business. It’s imperative to only carry forward what the business plans on utilising in the foreseeable future. Not only does historical data, especially transactional date, take up space but the process of migrating it can take up a lot of time. For a rundown on how the storage system in Business Central works, click here.

The size of the ERP system required

Typically, businesses will migrate to an ERP of a similar size, or look to get something which can scale upwards, coinciding with business growth plans. It’s less likely businesses would choose to scale down with regards to ERP capability. Exceptions to this may be when businesses are separated into different units or there is a drive to simplify outdated processes. As a result of scaling down, you may lose out on functionality available to users on the previous system. This in turn leaves two choices: leave the data and functionality behind or customise the new system to allow for it. The problem is, the more you customise ERP, the more potentially risky and time consuming you make future upgrades. Therefore, where possible, it’s best to choose an ERP system that includes the majority of functionality you need as standard.

It’s not your day job

One of the factors that has the greatest impact is the availability of the people required for the project. For us, it’s our day job and we can plan it. For the client, we are asking their people, typically the busiest people with the most knowledge, to do a lot of work on top of their normal duties. How much time can these people realistically commit to the project?

The normal routine of implementations at Probitas

Firstly, the typical procedure begins with reviewing the requirements of the customer and determining the overall scope of work. Next, we will agree a methodology for the project. Depending on a number of factors, such as the complexity of the project, this will be either a waterfall or agile methodology. The next step will be to draw up a project plan and agree the timescale. Detailed analysis, development, testing, training and data migration all follow in various iterations, according to the methodology.

In truth, factoring in the availability of everyone involved can’t be understated! We also need to decide upon which areas of the system will and won’t be used.

Average length of time required for an implementation

So, how long does a Business Central implementation take? In our experience, it is the availability of client resources that drives the timescale. Unless it’s a very simple project then we would allow a minimum of 3 months. We tend to do more complex projects which generally take 6 to 12 months. This can seem like a long time, but it’s better to do it right first time than have to fix it later. Where systems are implemented too quickly, gaps are left, data is inaccurate and the customers don’t know how to use the system to its full potential.

The key takeaway is, you don’t want to have to redo the implementation further down the line or change partner. With respect to changing partners, Probitas have taken on a number of unhappy clients who’ve suffered from improper implementations in the past. If you’d like to read our post on the topic, click here.

Closing remarks

A little while ago we posted our thoughts on what makes or breaks an implementation, something wholly related to this topic; click here to give that a read. That post focuses more on what the Dynamics partner and customer can do to enhance the implementation experience. If you’d like to follow us on LinkedIn, click here and see our posts as soon as they go out!

%%footer%%