Current State
Upgrading to Dynamics 365 for Operations from Dynamics AX - part 3.
Part 3 of 4 things you really need to know.
The most common (and logical) questions I’m asked are ‘how long will it take?’ and more importantly, ‘how much will it cost?’
Unfortunately, some form of discovery is needed up front before I can give an answer. Just like a builder asked to estimate the time and costs of renovating a house, even if the owner can describe the building size, number of rooms, house type etc, an onsite inspection is essential before a realistic estimate can be made. Even putting it in a range is challenging, as influencing factors include:
So to make the time and costs clear from the outset, your Microsoft Partner will create a map which details the complexities of your current solution, and then produce a future-state map of the new version. This demonstrates how all the parts of the new solution integrate, and gives a great visual blueprint to refer back to throughout the project. I’ve always found my solution maps on the project wall, well viewed and under discussion.
Current State
Future State
The devil is in the detail
While I draw on the many customer upgrades I’ve done in the past and my knowledge of the architectural changes in Dynamics 365 for each new project, it’s important to remember that there will always be unknowns. You should always factor in contingencies (in terms of time and budget) to any planned upgrade. That way you won’t be caught out part-way through the project when those unknowns rear their ugly heads.
Another thing to factor in to a Dynamics 365 upgrade is the code sealing. Microsoft are ‘sealing off’ the application code over the next year, which means existing customisation must be rewritten as an ‘extension’, rather than using the old method of ‘overlaying’. As this blog is more business level than technical, I won’t expand here. However, there are some great blogs out there that dive into the technical details, and your Microsoft Partner can explain further if required. The point is, careful planning and execution is required to deliver an upgraded system that conforms to Dynamics 365’s new architectural principles.
Our two project approaches – cooking an egg
The following step by step breakdowns give you a basic idea of the major activities involved in an upgrade or a re-implementation. However, there’s more than one way to cook an egg, so bear in mind that these may not describe exactly how your unique project will run.
Re-implementation
As mentioned in parts 1 and 2 of this blog series, a re-implementation runs a lot like a full-blown ERP implementation. So these steps are likely to feel familiar if you’ve done that already. However, there are some subtle differences when moving from one version of Dynamics AX to another.
Step 1 - Solution Review
Your business consultant runs a series of workshops for each functional area, which fully reviews your current AX processes. The consultant needs to understand your business and identify areas for change in the upgrade to Dynamics 365 Operations, including business processes, data and modifications. At the same time, your subject matter experts have the chance to learn about new opportunities for process improvement. Your consultant documents all these points, and this becomes the macro design of your new system.
Step 2 – Design
A second set of workshop sessions with the consultant and key users from the business drills into the areas where change will occur. These might, for example, look at the effects of increased use of the system, or at modifications that need re-engineering due to changes between versions. The output of the design phase is the functional and technical design specs necessary to build the new system.
Step 3 – Build
The new environments are created once the solution review and design are finalised and signed off. At this point there’s usually a development freeze on the current solution, as well as a freeze on new projects to extend the system e.g. implementing new modules. Technical consultants migrate all the agreed customisations from the current solution into the new development environment, and work on them as required. This step requires little or no input from your business.
Step 4 – Configure
This step runs parallel to Step 3. Functional consultants and key users migrate the configuration, master data and opening balances from the current solution to the newly-created configuration environment. The result will look a lot like the final solution.
Step 5 – Unit Testing
Before handing the environment back to you for testing, the work performed in Steps 3 and 4 is checked against the functional and technical specs from the design phase. This may require some rework on the code or data migration steps, which is typically performed by the functional consultants. This step requires little or no input from your business.
Step 6 – User Acceptance Testing
The testing environment is handed back to you, along with a full test plan and test cases to drive the process. This part of the project is structured, documented and transparent. Consultants are available for support, but this stage is owned and driven by your business.
Step 7 – Go-live
Over the go-live weekend, the opening balances migrate and any other cutover activities specific to your business are performed. The new system is up and running with limited access to your old AX environment on the Monday. A full resource plan ensures you have both internal and external resources at your disposal. The success of this phase is hugely impacted by the level of testing done in Step 6. There are no shortcuts: test test test!
Upgrade/Technical Upgrade:
What’s the difference? Well, a non-technical upgrade takes a wider view, looking at improving processes, reducing customisation, reorganising data etc. A non-technical upgrade is similar to a re-implementation from a phase perspective. So the following steps focus on a straight-forward technical system upgrade. This doesn’t require the same level of input from your business, as the goal is a ‘like for like’ transfer of processes with no re-engineering (unless forced to by the system). The tasks are, obviously, more technical in nature, but there should still be a full user acceptance testing cycle at the end of the project that requires a high level of input from you to ensure the project’s success. The steps below outline the most basic upgrade, and assumes you’re moving from Ax2012 R3 to Dynamics 365 for Operations. If you’re on an older version, then you need to upgrade to AX2012 R3 first, but this can be done as a double hop in the same project (effectively doing Step 2 twice).
Step 1 - Solution Review
A business consultant runs series of workshops for each functional area of your current AX processes, with a view to understanding which ones will need the most testing, and if any re-design or re-engineering is required. If you’re starting out with a standard AX, the process should work smoothly as soon as the upgrade scripts are in place. However, modified areas may upgrade imperfectly without some re-design and re-engineering.
Step 2 – Upgrade
This is where the fun begins! Depending on which version you’re moving from and to, what ISVs you have, how many modifications your current solution has and so on, activities in this step will vary. But at a high level there are two objectives:
Documentation is the most critical part, as this process is repeated multiple times, and again on the cutover weekend. Having consultants and developers document all steps is crucial to ensuring repeatability and consistency.
Step 3 – Unit Testing
Before handing the environment back to you for testing, the work performed in Step 2 is checked and the system is matched against the agreed design from Step 1. This may require some rework on the code or data migration steps.
Step 4 – Test/Upgrade/Test/Upgrade/Test
The system is handed back to your key business users, along with a full test plan and test cases to drive the process. This step involves multiple cycles to make absolutely sure the upgrade can be repeated step by step and achieve the same outcome every time. Once proven, the system is ready to go-live.
Step 5– Go-live
The upgrade runs one final time on the go-live weekend. As the process may take both days, you might need to shut your systems down on Friday. But if all goes to plan, then your new system is up and running on Monday with limited access to your old AX. The testing in Step 4 should ensure a smooth journey, but if a new or unexpected issue arises during the cutover (for example, I’ve seen cases where the live servers had subtle differences which resulted in major knock-on problems), the most prudent thing to do is usually aborting the upgrade and setting a new date for going live.
Who’s who in the zoo
Having the right internal resources is critical for project success. And as with everything I’ve touched on in this blog, who and what you need can vary. This is a table of the most common resources. Ideally you’d have them all, and often one person can cover multiple roles:
This blog should give you sufficient knowledge of the steps and business resources needed at each point in an upgrade.
Fusion5 can carry out an upgrade assessment that helps you work out the right approach for your business and puts your mind at rest on the costs involved in upgrading to Dynamics 365.
So, now you have the information, and you know the effort involved. In the final part of this blog series, I’ll help you to answer the question: ‘Why is an upgrade the best thing for my business right now?’
