I am currently preparing to take the Microsoft Dynamics 365 + Power Platform Solution Architect certification. Or “MB 600” for short! As I prepare I plan to write revision notes in this post I will cover Support Go-Live.
Note: Microsoft have recently updated some of their terminology. Therefore we should consider the terms like CDS and Dataverse as interchangeable. For the exam I would expect them to begin using the term DataVerse at some point but that change is unlikely to be immediate. Meaning in the short term either term could be used. I created this blog post before the revised terms were announced. I have tried to apply updates but a few “outdated” references may still exist!
In an ideal world there wouldn’t be a support need for a perfectly architected solution! The reality is support is always needed after an implementation. The Solution Architect should be an active participant in the planning of post go-live support and the transition from “project mode” into business as usual.
Post go-live we would typically expect the role of the Solution Architect to be diminished. As on a day-to-day basis the Architect is unlikely to have an involvement. Although often I’ve seen a heighted period of support immediately after the initial production release, I think we can reasonable expect the Solution Architect to remain closely involved during this early period. Often this will involve helping progress any bugs or minor enhancements required post go-live. The Architect may also need to review various reports on system usage, network telemetry, storage capacity and much more. This will help them understand that the solution is being used as expected and is also performing in an optimal way.
This continued involvement of the Solution Architect post go-live helps ensure the team stays engaged as they need to stay involved until the “very end” to ensure success.
Microsoft Release Process
In addition to considering the customer’s release / deployment approach the Solution Architect will need to be aware of Microsoft’s release cadence /approach.
There are different types of releases that Microsoft might make to the Power Platform and Dynamics 365.
- Quick Fix Engineering (QFE) / Patches – in response to major issues or security risks Microsoft can make deployments worldwide within hours.
- Weekly patches – bug fixes, performance enhancements, stability improvements (etc) are pushed out on a weekly basis. These weekly updates could include new admin features or user facing customizations which you must opt into. But they wouldn’t typically include changes which are user facing by default.
- Twice annual release waves – Starting in April and October major changes which are user facing will be include in release waves. The release notes for these updates are published four months in advance of the wave starting. And you can “test drive” the changes two months prior to the release.
In line with the annual releases Microsoft publish roadmap details in release plan documents. The Solution Architect should be aware of what is on the roadmap that could impact the solution architecture. It maybe new features should be evaluated and decisions taken on when best to adopt the new capabilities. Often Microsoft release new features in a preview state, when this happens it maybe useful to evaluate the feature but until the full release version is available it is not recommended preview features are used for production purposes. (As they are likely to be changed or removed!)
Additionally, importantly along with each release wave Microsoft may announce feature deprecations. Typically when this happens the feature in question is still available but will no longer receive any updates and will potentially be completely removed from the Power Platform / Dynamics 365 in the fullness of time. The Solution Architect should therefore confirm no deprecated features are being used and when in use plan for their replacement.
Finally the Solution Architect should be mindful not to include any unsupported customizations. As doing this will ensure the fast paced updates from Microsoft do not adversely impact the solution.
Another topic the Solution Architect should monitor is how the customer’s licenses maybe impacted by feature deprecations or the bi-annual release waves. As it is not uncommon for new features to need new licenses!
Facilitate risk reduction of performance items
Often the activities involved in testing and go live preparation will come towards the end of the project life cycle but I suggest it might be important to understand that testing and readiness does not have to wait until the end of a project. Continuous testing can be used to keep all stake holders informed on solution quality and readiness, this can in turn improve your chance of success and lead to a smoother handover from “project mode” into business as usual.
Additionally post go-live it will be important to monitor the performance of applications.
For example reviewing the performance of your canvas apps should be an ongoing effort, you may (for example) be able to off load “work” completed in the canvas app into a Power Automate. And therefore create a more responsive UI. You may be able to use test studio to create repeatable tests for your canvas apps. This will allow regression testing and become an important part of your software development life cycle (SDLC). Test studio is a pretty new tool to help validate that canvas apps work as expected, you can read about it here.
The Solution Architect will help the customer understand the readiness of the system and any associated risks of known issues. In doing this they will help guide the customer towards an informed go live decision. Often the Solution Architect will know the system better than anyone so an informed risk assessment of the systems readiness is something the Architect is well placed to perform. They should know better than anyone what could break, what might not work as designed and what actions can be taken if the system goes down.
Troubleshoot data migration
During the testing phase, data migration should have been tested and the resulting data checked for completeness and accuracy. Repeating these tests multiple times should help ensure the final go-live migration operates as smoothly as possible.
With large implementations it may not be physically possible to migrate all of the historic data on day one. Therefore data migration plans maybe needed to prioritize which data gets imported first.
Review and advise in deployment planning
The Solution Architect will typically be part of the delivery team that will have been put in place to build and test the solution. It will be the Architects role to help build this team and validate any development and testing plans. During the implementation phase the solution architect will become key in triaging any development problems.
Creating a deployment plan is essential in ensuring all go live steps are completed and sequenced correctly. The Solution Architect may not be the person who actually creates the deployment plan but the Architect should expect to provide input into the plan and act as a reviewer.
The architect should whenever possible support the deployment process by identifying risks and help form a “plan B”. The Solution Architect is the “champion of the solution” and may often be the first port of call when the customer is unhappy with progress during deployment.
Some common go live problems (to be avoided) may include;
- No roll back plan – if the deployment goes bad what are we going to do? Can we roll back? (And has that roll back been tested?)
- Not enough testing – testing maybe very comprehensive but have you done enough real-world testing? Do the customizations really meet the users needs and does the system perform as expected with real user / data volumes?
- Outstanding defects not evaluated – perfection is rare but have any outstanding issues been properly evaluated. Is the impact of fixing now compared to post go live fully understood?
- Incorrect environment assumptions – avoid incorrect assumptions about end user workstations or network configurations.
The Architect should review deployment plans and seek out ways to streamline and simplify the plan. For example, can some of the data be migrated early or can we pre-deploy our mobile apps etc.
Additionally have all user logins been created, appropriate licenses assigned and do they all have the correct roles in the Dataverse (CDS). If possible get all users to access a dummy productions environment to help spot any issues early.
It may be the case that you have to deploy the new application as a “big bang”. But if possible consider if the old system can be run in parallel to the new. Meaning can we slowly move users over to the new system in a controlled manner. Or if a “big bang” is the only option then the Solution Architect may need to advise on the level of risk involved in this process.
Automate the go live
Consider how much of the go live deployment process can be automated. As an automated process is less likely to fail and is also more testable prior to the actual go live.
You may, for example be able to automate the creation is users, teams, business units. Or you may be able to automate the import / creation of reference data. (Microsoft’s configuration migration tool may assist with this.)
But if you do use any automations during the go live process take care to ensure they are well tested.
With or without automations it is essential to have a go-live check list and a timeline. Plus test this check list! Does it include everything and are the timings achievable / realistic. And have we allowed sufficient contingency for any issues that could crop up.
Review and advise with Go-Live Assessment
It may be true that the Solution Architect will be involved in any go / no-go decisions.
Often we may envisage that a solution will be perfect by the time of go-live. In reality this is rarely the case! It will be likely that the Solution Architect may need to help communicate details of any known issues that will be present at go-live. The Architect maybe called upon to evaluate the impact of fixing any outstanding issues now or once live. (In my experience fixing some issues post go live can be much more costly.)
Documentation at go-live maybe critical to ensure decisions, agreements, tasks and assumptions aren’t forgotten. A quick agreement reached in the hallway can quickly be forgotten! Any consents reached with the customer should be documented.
Plus any suggestions / recommendations made should be recorded, especially if the customer rejects a recommendation. You want to avoid someone incorrectly saying afterwards “why didn’t you tell us that??”.
Once the system is live the Solution Architect is often the first person who gets called when problems arise. They can help triage problems and isolate the root cause. In resolving go-live issues the Architect must consider the immediate impacts as well as the longer term. Can we mitigate the issue now with a “quick fix” whilst also considering a longer term solution to avoid future reoccurrences?
NEIL PARKHURST 
Leave a comment