Upgrading with Microsoft Sure Step


Microsoft Dynamics Sure Step 2010

Microsoft Dynamics Sure Step 2010

The smart guide to the successful delivery of Microsoft Dynamics Business Solutions

  • Learn how to effectively use Microsoft Dynamics Sure Step to implement the right Dynamics business solution with quality, on-time and on-budget results.
  • Understand the review and optimization offerings available from Microsoft Dynamics Sure Step to further enhance your business solution delivery during and after go-live.
  • Gain knowledge of the project and change management content provided in Microsoft Dynamics Sure Step.
  • Familiarize yourself with the approach to adopting the Microsoft Dynamics Sure Step methodology as your own.
        Read more about this book      

(For more resources on Microsoft, see here.)

Upgrade assessment and the diagnostic phase

In this section, we will discuss the process, particularly the Upgrade Assessment Decision Accelerator offering, in more detail.

We begin by reintroducing the diagram showing the flow of activities and Decision Accelerator offerings for an existing customer. You may recall that the flow is very similar to the one for a prospect, with the only difference being the Upgrade Assessment DA offering replacing the Requirements and Process Review DA.

(Move the mouse over the image to enlarge.)

As noted before, the flow for the existing customer also begins with Diagnostic Preparation, similar to that for a prospect. The guidance in the activity page can be leveraged to explain/understand the capabilities and features of the new version of the corresponding Microsoft Dynamics solution that is being considered. When interest is established in moving the existing solution to the current version of the solution, the next step is the Upgrade Assessment DA offering, which is the key step in this process.

The Upgrade Assessment Decision Accelerator offering

The Upgrade Assessment DA is the most important step in the process for an existing Microsoft Dynamics customer. The Upgrade Assessment DA is executed by the services delivery team to get an understanding of the existing solution being used by the customer, determine the components that need to be upgraded to the current release of the product, and determine if any other features need to be enabled as part of the upgrade engagement.

In combination with the Scoping Assessment DA offering, the delivery team will also determine the optimal approach, resource plan and estimate, and overall timeline to upgrade the solution to the current product version.

Before initiating the Upgrade Assessment DA, the services delivery team should meet with the customer to ascertain and confirm that there is interest in performing the upgrade. Especially where delivery resources are in high demand, this is an important step that the sales teams need to carry out before involving the delivery resources such as solution architects and senior application consultants. Sales personnel can use the resources in the Sure Step Diagnostic Preparation activity to understand and position the current capabilities of the corresponding Microsoft Dynamics solution.

Once customer interest in upgrading has been determined, the services delivery team can employ the Upgrade Assessment DA offering. The aim of the Upgrade Assessment is to identify the complexity of upgrading the existing solution and to highlight areas of feature enhancements, complexities, and risks. The steps performed in the execution of the Upgrade Assessment are shown in the following diagram.

Microsoft Sure Step

The delivery team begins the Upgrade Assessment by understanding the overall objectives for the Upgrade. Teams can leverage the product-specific questionnaires provided in Sure Step for Microsoft Dynamics AX, CRM, GP, NAV, and SL. These questionnaires also include specific sections and questions for interfaces, infrastructure, and so on, so they can also be leveraged in the following steps.

One of the important tasks at the outset is to review the upgrade path for Microsoft Dynamics and any associated ISV software, to determine whether the upgrade from the customer's existing product version to the targeted version of Microsoft Dynamics is supported. This will have a bearing on how the upgrade can be executed—can you follow a supported upgrade path, or is it pretty much a full reimplementation of the solution?

The next step in executing the Upgrade Assessment is to assess the existing solution's configurations and customizations. In this step, the delivery team reviews which features of Microsoft Dynamics have been enabled for the customer, including which ones have been configured to meet the customer's needs and which ones have been customized. This will allow the delivery team to take the overall objectives for the upgrade and determine which of these configurations and customizations will need to be ported over to the new solution, and which ones should be retired. For example, the older version may have necessitated customizations in areas where the solution did not have corresponding functionality. Or perhaps the solution needed a specific ISV solution to meet a need. If the current product version provides these features as standard functionality, these customizations or ISV solutions no longer need to be part of the new solution.

The next Upgrade Assessment step is to examine the custom interfaces for the existing solution. This includes assessing any custom code written to interface the solution to third-party solutions, such as an external database for reporting purposes. This step is followed by reviewing the existing infrastructure and architecture configuration so that the delivery team can understand the hardware components that can be leveraged for the new solution. The delivery team can provide confirmation on whether the existing infrastructure can support the upgrade application or if additional infrastructure components may be necessary. The final step of the Upgrade Assessment DA offering is for the delivery team to complete the detailed analysis of the customer's existing solution and generate a report of their findings. The report, to be presented to the customer for approval, will include the following topics:

  • The scope of the upgrade, including a list of functional and technical areas that will be enhanced in the new solution.
  • A list of the functional areas of the application categorized to show the expected complexity involved in upgrading them. If there are areas of the existing implementation that will require further examination or additional effort to upgrade successfully due to the inherent complexity, they must be highlighted.
  • Areas of the current solution that could be remapped to new functionality in the current version of the base Microsoft Dynamics product.
  • An overall recommended approach to the upgrade, including alternatives to address any new functionality desired.

The Upgrade Assessment provides the customer early identification of issues and risks that could occur during an upgrade so that appropriate mitigating actions can be initiated accordingly. The customer can also get a level of confidence that an appropriate level of project governance for the upgrade is available, as well as that the correct upgrade approach will be undertaken by the delivery team.

In the next sections, we will discuss how the Upgrade Assessment DA becomes the basis for completing the customer's due diligence, and sets the stage for a quality upgrade of the customer's solution.

When to use the other Decision Accelerator offerings

After the Upgrade Assessment DA has been executed, the remaining DA offerings may also be needed in the due diligence process for the existing Microsoft Dynamics customer. In this section, we will discuss the scenarios that may call for the usage of the DA offerings, and which ones would apply to that particular scenario.

From the Upgrade Assessment DA, the delivery team determines the existing business functions and requirements that need to be upgraded to the new release. Using the Fit Gap and Solution Blueprint DA offering, they can then determine and document how these requirements will be ported over. If meeting the requirement is more than implementing standard features, the approach maybe a re-configuration, custom code rewrite, or workflow setup. Additionally, if new features are required as part of the upgrade, these requirements should also be classified in the Fit Gap worksheet either as Fit or as Gap. They should also be further classified as Standard, Configuration, or Workflow as the case may be for the Fits, and Customization for the Gaps.

The Architecture Assessment DA can be used determine the new hardware configuration for the upgraded solution. It can also be used to address any performance issues up-front through the execution of the Proof of Concept Benchmark sub-offering.

The Scoping Assessment DA can be used to determine the effort, timeline, and resources needed to execute the upgrade. If it was determined with the Upgrade Assessment DA that new functionality will be introduced, the delivery team and the customer must also determine the Release plan. We will discuss upgrade approaches and Release planning in more detail in the next section.

It is important to note that all three of the above Decision Accelerator Offerings— the Fit Gap and Solution Blueprint, the Architecture Assessment, and the Scoping Assessment can be executed together with the Upgrade Assessment DA as one engagement for the customer. The point of this section is not that each of these offerings needs to be positioned individually for the customer. On the contrary, depending on the scope, the delivery team could easily perform the exercise in tandem. The point of emphasis in this section for the reader is that if you are assessing an upgrade for the customer, you should be able to leverage the templates in each of the DA offerings, and combine them as you deem fit for your engagement.

Lastly, the Proof of Concept DA offering and Business Case DA offering may also apply to an upgrade engagement, but typically only for a small subset of customers. Examples include customers who maybe on a very old version of the Microsoft Dynamics solution so that they pretty much need a re-implementation of the solution with the new version of the product, or customers that need complex functionality to be enabled as part of the upgrade. In both these cases, the customer may request the delivery team to prove out certain components of the solution prior to embarking on a full upgrade, in which case the Proof of Concept DA may be executed. They may also request assistance from the delivery team to assess the return on investment for the upgraded solution, in which case the Business Case DA may be employed.

Determining the upgrade approach and release schedule

As noted in the previous section, the customer and the delivery team should work together to select the right approach for the upgrade during the course of the upgrade diagnostics. Sure Step recommends two approaches to Upgrades:

  • Technical upgrade: Use this approach if the upgrade mostly applies to application components, such as executable files, code components, and DLLs. This approach can be used to bring a customized solution to the latest release, provided the application functionality and business workflow stay relatively the same.
  • Functional upgrade: Use this approach if new application functionality or major changes in the existing business workflows are desired during the course of the upgrade. Additional planning, testing, and rework of the existing solution are inherent in this complex upgrade process, and as such more aligned to a Functional upgrade. Functional upgrades are typically performed in multiple Releases.

The following diagram depicts the two Upgrade approaches and the Release schedules.

Depending on the scope of the upgrade, the customer engagement may have one or more delivery Releases. If for example, the customer's solution is on a supported upgrade path, the Technical Upgrade maybe delivered in a single Release using the Sure Step Upgrade project type. If the new solution requires several new processes to be enabled, the Functional Upgrade may be delivered in two or more Releases. For example, if the customer needs advanced supply chain functionality such as production scheduling and/or advanced warehousing to be enabled as part of the upgrade, the recommended approach is to first complete the Technical Upgrade using the Sure Step Upgrade project type to port the existing functionality over to the new product version in Release 1, then add the advanced supply chain functionality using the Rapid, Standard, Agile, or Enterprise project types in Release 2.

As noted earlier, the DA offerings can be executed individually or in combination, depending on the customer engagement. Regardless of how they are executed, it is imperative that the customer and delivery team select the right approach and develop the necessary plans such as Project Plan, Resource Plan, Project Charter, and/or Communication Plan. These documents should form the basis for the upgrade delivery Proposal. When the Proposal and Statement of Work are approved, it is time to begin the execution of the solution upgrade.



        Read more about this book      

(For more resources on Microsoft, see here.)

Delivering the upgrade

In the previous section, we discussed how we set up for the upgrade delivery. We now focus on the delivery of the upgrade itself, using the Sure Step Upgrade project type.

We discussed the two approaches to upgrading with Sure Step in the previous section, the Technical Upgrade and the Functional Upgrade. The common denominator for both these approaches is the Sure Step Upgrade project type, which provides the underlying workflow for the only Release for the former approach and the first Release for the latter approach. A screenshot of the Sure Step Upgrade Project Type is shown next:

As shown in the diagram, the Sure Step Upgrade project type follows the waterfall method, and with the five phases, Analysis, Design, Development, Deployment and Operation. Just as in the Standard, Rapid, and Enterprise project types, the activities in these phases are grouped under the nine cross phase processes.

The Analysis and Design phases

The Analysis phase builds on the discovery efforts undertaken in the Diagnostic phase with the goal to finalize the requirements (the what) and the fit gap analysis (the how), and initiate the data upgrade, while the Design phase is used to finalize and gain approval on the solution design before beginning development.

The following diagram depicts some of the key activities in the Analysis and Design phases of the Sure Step Upgrade project type.

Microsoft Sure Step

As you would expect on typical projects, the Upgrade engagement starts with a Project Kickoff. The objective of this activity is to ensure that the team members understand the overall objectives for the upgrade engagement, and each other's roles and responsibilities in the journey. Items such as what is the Communication Plan, who is responsible for keeping the team and the stakeholders in the know, and what will be the vehicle to achieve that, are just some of the important points to get clarified at this juncture.

This is followed by the Solution Overview activity, to provide an introduction of the Microsoft Dynamics solution to those on the team who were not involved in the assessment phase. This sets the stage for the key steps of finalizing the requirements and scope to move to the Design activities.

The next two activities, Requirements Finalization and Fit Gap Finalization, are very important, but they also come into question at times. The question is usually regarding why these activities are called out both in the Diagnostic phase and in the Analysis phase. Quite simply, the answer is that depending on how in-depth the discovery effort was, the work in this phase may mostly entail an affirmation of the scope. But that is a big IF! IF all the key users were involved in the Diagnostic activities, IF all the requirements were considered in the Diagnostic phase, and IF all the questions were answered and issues were resolved during the execution of the Decision Accelerator offerings. IF the answer to any of the above is no, it is important that these activities are executed and the deliverables finalized in the Analysis phase.

For the Requirements Finalization activity, typically a Requirements Workshop is conducted, to finalize the Functional Requirements Document (FRD). The FRD should clearly note the existing business functions and requirements that will be upgraded to the new release, and also any additional requirements (in other words, new functionality) to be delivered as part of the upgrade. The Fit Gap Finalization builds on the requirements, using the Fit Gap Worksheet to determine how these requirements will be delivered—by implementing standard features, configuration or re-configuration, workflow setup, or new/rewritten custom code. Again, depending on the effort that was carried out with the Upgrade Assessment DA, the FRD, and Final Fit Gap may be easily accomplished. But both are key documents that must be approved by the customer's business sponsor by the end of the Analysis phase.

Data Upgrade Preparation is another key activity in the Analysis phase. This activity constitutes the start of the Data Migration activities, beginning with the identification of existing data sources, including the existing Microsoft Dynamics solution, any ISV solutions, and any interface programs. Also in scope is the identification of additional data sources and how they will be accessed. Additional items for consideration include the state of the source data (amount of data cleansing required, who, how, where, and when will cleanse the data, and so on), any legal requirements for data retention, and strategies for warehousing of data external to the Microsoft Dynamics solution. Depending on the state of the source date, the team may also need to identify whether Extract Transform and Load (ETL) tools may be needed for the data cleansing and migration efforts. It should also be determined which parts of the data migration will be automated, and which, if any, require manual execution.

While the goal of the Analysis phase is to understand the requirements to establish the overall scope for the upgrade engagement, the Design phase is used to define how the technical upgrade will be implemented. Objectives include planning the steps for executing the upgrade and identifying conflicts for upgrading custom code. It also includes proactively planning for potential post-upgrade issues and reviewing the existing integration and interfaces between Microsoft Dynamics and third-party solutions to determine whether they need to be upgraded to work with the newer version of the Microsoft Dynamics solution. Accordingly, the key Design phase activities include Data Upgrade Checklist for planning and executing the upgrade, Existing Code Review to analyse and identify any conflicts created by the customizations to the existing solution, and Existing Integrations & Interfaces Review to determine which existing integrations and interfaces need to be upgraded. If product tools are available to support these activities, links to the corresponding tools are referenced in Sure Step. For example, Microsoft Dynamics AX provides an upgrade checklist utility with required and optional steps denoted in a sequential manner to provide guidance and assistance during the upgrade process, as well as a Compare Tool for Microsoft Dynamics AX to help determine and resolve code conflicts for the solution customizations. Since Microsoft Dynamics AX has a unique architecture where the code can be saved in different layers, (such as a USR layer for the customer users, VAR layer for the partners, and so on), the Compare tool also provides the ability to compare and detect code conflict during the upgrade one layer at a time or simultaneously in all layers.

The completion of the Design phase indicates that all the customer requirements for the solution have been analyzed and the functional and/or technical designs completed to initiate development efforts for the upgrade. A phase review at the end of each phase is recommended for any size project, but certainly for larger engagements. Besides getting agreement from the customer on the completion of the phase, it also allows the delivery team to document lessons learned, outstanding issues and risks, and mitigating actions for them.

The Development, Deployment, and Operation phases

The goal of the Development phase is to set up the application for the upgrade, which may include ISV solutions to complement the standard Microsoft Dynamics product. This phase also encompasses upgrading any customizations, integrations and interfaces, and corresponding data elements. The Deployment phase is the culmination of the upgrade delivery efforts, resulting in the transition of the customer to the new solution. The Operation phase encompasses the post go-live stabilization of the solution and transition to support.

The following diagram depicts some of the key activities in the Development, Deployment, and Operations phases of the Sure Step Upgrade project type.

Microsoft Sure Step

The key Development phase activities in the Upgrade project type include Application & ISV Upgrade, Customization Upgrade, Production Environment Setup, Integration & Interfaces Upgrade, and Data Verification & Benchmarking. Just as with the prior phases, the activities may include links to product tools or white papers where applicable, such as the Custom Coding Best Practice for Microsoft Dynamics CRM. Activities also provide templates such as Test Scripts and Environment Specification documents that can be leveraged by the delivery teams as a starting point to document their efforts.

While the Development phase represents a large percentage of the efforts of the upgrade engagement, the Deployment phase is where the efforts come to fruition. User Training is a key activity in this phase wherein the end users get handson training on the new system prior to go-live. Depending on the size of the organization, training could be executed in groups—typically, the delivery team will train the key users or a core set of users who will then act as trainers for the remaining end users.

Following the completion of user training, the organization can begin User Acceptance Testing (UAT). UAT is a key validation point by the customer organization of the new solution—user acceptance of the solution indicates the customer is ready to go live with the new solution. Sure Step provides several product and industry focused UAT script templates that the delivery teams should leverage. These detailed scripts walk the user through the steps for executing a given process or functionality. In many instances, delivery teams have also leveraged the details in these scripts to develop Training guides for the previous activity. An example of one of the Test Scripts for Microsoft Dynamics NAV is shown in the following screenshot:

Once this acceptance is obtained, the last activity prior to Go Live is Data Migration to Production, wherein the cleansed data from the existing system are migrated to the new system.

After the solution going live, the project moves to the Operation phase. The key activities in this phase include Transition Solution to Support to transfer the solution from the delivery team to the Support team, and Project Closure to finalize and wrap-up the project.


In this article, we learned the approaches to upgrade existing Microsoft Dynamics to the latest product release, including assessing the existing solution and executing the upgrade.

Further resources on this subject:

You've been reading an excerpt of:

Microsoft Dynamics Sure Step 2010

Explore Title