Chapter 15: Go-Live Strategies

In this chapter, you will roll out a phased go-live strategy for our fictional digital transformation project at Inveriance Corps. You will learn how to anticipate potential performance issues and resolve performance bottlenecks across the full range of Power Platform components. By doing so, you will understand how to troubleshoot data migration and resolve identified deployment issues.

Solution architects tend to understand Power Platform implementations better than most project members. It is essential to leverage this knowledge to push the project through to completion, educating the testing team on the architecture so that all areas are validated, helping triage issues, and helping define a go-live strategy.

In this chapter, we are going to cover the following topics:

• Selecting a go-live strategy
• Preparing for go-live
• Rolling out the production environment

By the end of this chapter, you will be able to identify factors that impact go-live readiness and take the appropriate remedial actions for a successful Power Platform go-live.

Selecting a go-live strategy

Power Platform projects range from solutions that provide the business with brand-new functionality or systems that partially or fully replace existing services within the organization. Brand-new services tend to have fewer dependencies and a more straightforward go-live rollout, as users do not need to migrate or “move” from one system to another. When the time comes to switch on the lights, having defined a go-live strategy, activities, and readiness checklists will help you preempt potential hurdles.

Whether releasing a brand-new application or replacing an existing service, Power Platform solution rollouts use either a phased approach or a single go-live release. This section will discuss the benefits of a phased rollout versus what is often called the big-bang approach.

Selecting a phased go-live strategy

Power Platform solutions lend themselves to phased releases due to the modular nature of their components, databases, and automation capabilities. A phased go-live strategy usually involves an initial release containing a subset of the full functionality, including the minimum set of features that make the solution viable. The initial release is followed by subsequent releases that further enhance the solution and provide users with additional functionality.

Let’s look at the benefits and drawbacks of a phased go-live strategy.

Pros and cons of a phased go-live strategy

The main pros and cons phase Power Platform releases are summarized as follows:

Pros:

• Earlier return on investment (ROI): Releasing smaller portions of a solution while the rest of the application is developed and tested means the business can benefit from Power Platform sooner.
• Reduced operational risk: Multiple phased releases result in a lower operational risk level from each release than a single-release approach.

For example, when rolling out a new customer onboarding solution, the first release may include personal customers, while the second phase may cater to business customers. In this example, the business customer base is unaffected by the initial release, thus reducing the risk to the business.

• Reduced complexity per release: Each phase concerns itself with a subset of the target capabilities. Therefore, the implementation of each release is more manageable, allowing the team to focus on functionality specific to each release.

Cons:

• Potential refactoring cost risks: Demanding release timescales may lead to design decisions in the earlier phases of the project that are incompatible with requirements raised in a subsequent stage. While solution architects aim to design extendable solutions and cater to upcoming needs, a phased release approach adds the element of surprise to a certain extent. These surprises may result in refactoring costs and additional implementation time in the project’s later phases.
• Co-ordination of parallel work streams: Phased releases typically result in parallel work streams, where portions of the implementation team are focused on delivering a given release. At the same time, another group may be required to start work in the release that follows. It typically falls on the solution architect to devise a framework that allows multiple workstreams to work in parallel. Source control, testing, development environments, and release management of each parallel workstream will need to be coordinated, adding to the complexity of the project rollout.

Phased rollouts have become the preferred approach for Power Platform projects, and they provide clear benefits to the business in minimizing operational risk and earlier ROI. As a solution architect, you will balance the benefits to the organization against the additional overheads inherent in coordinating parallel work streams.

You will also aim to reduce the need for refactoring in later phases of the project by understanding the overall set of requirements for upcoming project phases. You may then allocate the time to design a solution that will cater to known forthcoming business needs, architecting an extensible solution that can handle surprise requirements.

Minimizing risks with a phased go-live roadmap

A phased rollout is effectively a promise to deliver a full set of functionality, in stages, to the business. A schedule usually backs up this promise for when each feature will be made available. Solution architects work with the business to agree on the release roadmap for a Power Platform solution while considering implementation and testing estimates and business priorities.

The release roadmap allows solution architects to focus on specific feature sets for the earlier phases. It also provides an overarching view of the full capabilities to be delivered. The architectural design can then prioritize the delivery of the project’s earlier stages while still being extendable to include the functionality required by the complete feature roadmap.

Phased go-live strategy conclusions

Phased go-live rollouts tend to be the preferred release strategy for Power Platform solutions thanks to their ability to minimize operational risk to the business and quicker ROI. They are well suited for larger implementations that could typically take over 6 months to deliver in their entirety.

The benefits of a phased rollout also come with the potential for additional mid-project refactoring costs and overheads while managing parallel work streams. If the benefits of a phased rollout do not outweigh the risks, a single-release implementation may be the most suitable approach.

Selecting a big-bang go-live strategy

A single release into production may be the most suitable strategy when the project’s size and complexity do not warrant a phased approach. There are also instances where dependencies between deliverables mean a phased rollout is not technically feasible.

Pros and cons of a big-bang go-live strategy

The pros and cons of adopting a big-bang go-live strategy are as follows:

Pros:

• A focused delivery stream: All implementation team members have a clear target in mind, and all workstreams are focused on delivering a single go-live target. The solution architect can define a simplified development framework that doesn’t need to coordinate parallel work streams and multiple phases.
• Resolves inter-deliverable dependencies: Dependencies between deliverables can sometimes make it difficult or technically unfeasible to deploy these in phases. In those instances, the big-bang approach would help resolve those inter-deliverable dependencies, as they are all deployed into production at the same time.

Cons:

• Longer lead time to ROI: Delivering all required functionality as part of one large release usually means the lead time to go live is greater than if the project had been released in stages. The business must wait for all the functionality to be built before getting an ROI.

Big-bang go-live strategy conclusions

Opting for a single large release into production versus a phased approach reduces the complexity of the team’s implementation dynamics. All team members are focused on a single goal and one large go-live target. This approach is often used for lower complexity projects spanning less than 6 months from initiation to go-live.

The next section discusses the preparation activities required for a successful go-live.

Preparing for go-live

Planning the launch of a Power Platform application is crucial to its success. A wide range of systems, users, and business areas must be coordinated and aligned for a solution to go live without a hitch. Solution architects work with product owners, IT teams, business analysts, and key stakeholders to identify the resource needed for go-live, define responsibilities during the cutover period before launch, and define a go-live checklist.

This section discusses each area to be planned before the product launch.

Identifying the resources required to go live

Launching a Power Platform solution requires the support of several resources within the implementation team, third-party suppliers (where applicable), and groups within the organization itself. Solution architects understand the makeup of the Power Platform solution better than anyone. They can identify the individuals/teams whose actions will be required during the cutover stage, go-live day, and post-launch.

The following resources are typically required for go-live:

• The Power Platform implementation team: The individuals involved in the solution’s development and implementation will be ideally placed to facilitate the smooth transition of the system into production.
• The Power Platform test team: The team responsible for validating the requirements are implemented correctly is also ideally placed to validate the production environment is ready for the big switch-on. They will typically validate that production functionality and integrations are fully functional.
• The procurement team: The organization’s procurement team is in charge of purchasing the Power Platform licenses needed for production use.
• The Active Directory administration team: The team or individual that will be responsible for provisioning Microsoft 365 users for access to the Power Platform applications and services, including license assignment. The team will require instructions on which AD security groups to assign licenses.
• The legacy system administration team: When a Power Platform application replaces an existing legacy system, the administrators or owners of the current system will typically be involved to ensure the migration process goes smoothly.
• The integrated systems owners: Power Platform applications often integrate with other systems inside and outside the organization. The owners and administrators of these integrated systems will be responsible for ensuring production instances are ready and accessible and ready to be connected on go-live day.
• The key stakeholders: The individuals whose day-to-day activities will be transformed with the introduction of the new Power Platform applications. These users will be instrumental in facilitating the transition into production and coordinating the user base to access the newly launched system.
• The change advisory board: If the organization has an active change management team or a change advisory board (CAB), they will be involved in reviewing the upcoming Power Platform product launch. Solution architects typically work with the CAB, preparing a rollout and rollback strategy for the solution and meeting with the change management team to get a sign-off for the system’s launch.
• The business-as-usual support team: The team that will be responsible for supporting the new Power Platform solution once it’s live. They will need to be brought up to speed on the general support actions and typical troubleshooting steps. An operational support guide document may be created, guiding the team on the regular maintenance tasks and day-to-day user support.
• The IT network team: Depending on the types of Power Platform integrations, the organization’s IT network management team may need to change the internal and perimeter network systems.
• The pentest team: Typically outsourced to an external organization, the penetration testing team is responsible for identifying any vulnerabilities in Power Platform applications and integrations. The results of the penetration tests will be used to make adjustments to the configuration as needed.
• The IT security team: Where applicable, the organization’s security team will be involved in validating the storage and management of credentials, the strategy for rotating secrets, and ensuring any the results of the penetration tests are reviewed and that any gaps in the security of the system addressed before launch.
• The users: These are the individuals and teams that will be using the new Power Platform applications and services. The training materials and the communication strategy, which will be discussed later in this chapter, will help ensure the users are ready to use the application on day one.

Depending on the complexity of the Power Platform solution and the size of the organization, additional individuals and teams may need to be brought into the go-live plan. Solution architects understand each of the components that make up a Power Platform solution and the individuals that can make each area of the system work. They then collaborate with them to make the launch happen.

Training users and maximizing adoption

Power Platform applications are typically designed with their target users in mind. Solution architects coordinate the creation of training materials to help users get the most out of their newly launched system. The following activities will help provide users with a clear understanding of the system, helping the solution get off to a good start.

Activities to maximize user understanding of the system and its adoption

The following list describes the typical activities and artifacts that are used by a Power Platform implementation project to facilitate understanding and adoption of the system:

• Training documentation:

Typically, this is a PowerPoint or Word document listing step-by-step instructions. Depending on the size of the solution and the number of teams working on the system, creating separate targeted training documents for each team will help focus the material and make it more relatable to each team’s day-to-day activities.

• Recorded training videos:

This is a recorded video walking through each of the activities users will have to perform during a typical day. This will also help cement their understanding of the system. Typically, short videos targeted at specific tasks will allow individuals to use these recorded videos as a training catalog they can refer to quickly when a question arises.

• Hands-on training sessions:

Live training sessions with the users before go-live will help solidify the user’s understanding of the system. These training sessions are typically carried out in a pre-production environment and improve user adoption by allowing users to try out the application. Through these hands-on training sessions, users can carry out tasks in a safe environment.

These training activities are typically coordinated or performed by solution architects. They aim to help users make the most of their new Power Platform application and cement user adoption, which is critical to the project’s success.

Defining the post-go-live capacity management and monitoring plan

During the project’s analysis, implementation, and testing stages, Power Platform capacity management must be considered at every step. The consumption of Power Automate Cloud Flows, the Dataverse API’s usage, and database storage capacity are key factors that will require continuous management and monitoring before and after go-live.

Capacity management considerations and actions before go-live

Solution architects reassess the following capacity allocations for a Power Platform solution before go-live.

Monitoring Power Automate Cloud Flow consumption

Solution architects closely monitor the consumption of Power Automate billable actions to ensure their usage does not breach the licensed capacity limits during the design phase.

Step 1 – export the Cloud Flows billable actions analytics

Each Cloud Flow analytics may be viewed via the See analytics menu option:

Figure 15.1 – Viewing Cloud Flow analytics

The analytics can be exported to Excel via the Export data menu:

Figure 15.2 – Exporting cloud-billable action analytics

The exported spreadsheet contains the billable actions for a specific flow for the previous days:

Figure 15.3 – The exported Cloud Flow billable action statistics

Step 2 – combine the billable flow counts for all flows onto a pivot table

The exported flow billable action statistics can then be collated into a worksheet that can be analyzed using an Excel Pivot Table. The resulting pivot table can then present a summarized analysis of the total Cloud Flow billable actions consumption per day:

Table 15.1 – Pivot table listing the total Cloud Flow billable actions consumption per day

Step 3 – project the daily billable flow action count based on expected production loads

The information from the spreadsheet can then be used to project the total Cloud Flow billable actions consumption per day:

Table 15.2 – Pivot table listing the total Cloud Flow billable actions consumption per day

Step 4 – propose a licensing strategy that supports the projected Cloud-billable action load

Having identified the projected Cloud Flow billable action consumption per day, you can propose a licensing structure that will cover the capacity demands of the application once it’s in production:

Table 15.3 – Example of the proposed Power Automate capacity add-ons required

The preceding table illustrates the proposed Power Automate capacity add-ons required to cater to a Power Platform application that processes a projected 100, 200, and 400 applications per day.

Monitoring Dataverse API usage

The Power Platform Dataverse API has strict usage and service protection limits. Solution architects monitor API usage using the Dataverse analytics page to identify processes that might potentially breach these limits and degrade the application’s performance:

Figure 15.4 – Dataverse API analytics page

Monitoring available storage capacity

The available storage is regularly monitored to ensure sufficient capacity for the system’s operation. Monitoring the storage capacity is particularly important as we approach the solution’s launch day. The Capacity page in the Power Platform admin center provides an overview of the storage used by the various environments:

Figure 15.5 – Power Platform storage capacity monitoring

Based on the current and projected usage of the system, solution architects can identify whether additional storage capacity should be purchased for the production environment to perform without reaching its capacity limits.

Defining a post-launch capacity monitoring plan

Having reviewed the system capacity requirements and resulting licensing needs during the implementation and go-live preparation stages, solution architects define a plan for continued monitoring. This continuous monitoring strategy will form part of an operation support guide discussed later in this chapter, which the business-as-usual support team will reference.

Planning the go-live cutover (who will do what and when)

Launching a Power Platform solution usually requires a carefully scripted set of actions to be carried out in sequence. Solution architects work with the teams and individuals to define a cutover strategy, a schedule for the pre-go-live activities, and perform a dry-run to iron out any issues.

Defining a cutover strategy

The cutover strategy identifies the following:

• What will be done?

The high-level functionality that will be delivered (Power Pages onboarding an application for new retail customers and supporting a Model-Driven app backend)

• Who will do it?

The roles, individuals, and teams that will be involved in the cutover. The following table shows an example of this:

Table 15.4 – Distribution of go-live responsibilities

• When will it be done?

The date when the Power Platform solution will go live. The cutover strategy also defines when and how a rollback will take place. Having defined the general cutover strategy, we can create a cutover plan.

Creating a cutover plan

The cutover plan lists the various steps that need to be completed before go-live, when they will be carried out, and by whom. The following is an example cutover plan:

Power Platform go-live date: 01-03-2022

Table 15.5 – Sample cutover plan

Rehearsing the cutover to go-live

Once the cutover strategy and rollout schedule have been defined, the plan is put through its paces. This test run helps identify any issues or gaps in the rollout of the Power Platform process.

Ramping up the operational support activities

Once the Power Platform solution is live, the organization’s support teams will play a role in the day-to-day maintenance and management of the system. Depending on the size and complexity of the implementation, solution architects may create an operational support guide document to facilitate this transition.

The operational support guide will typically cover the following topics:

• Introduction to the Power Platform solution
• Environment list
• An itemized list of all architectural and functional components to be supported
• Regular maintenance, including scheduled activities and rotation of secrets
• Managing product updates
• User onboarding and removal
• Typical support activities and a troubleshooting guide

The organization’s support team then uses the operational support guide to service the user base and perform ongoing maintenance tasks.

Preparing a communication plan

The Power Platform user base and its impacted business units are typically notified of the upcoming launch of Power Platform applications. The timing and format of this communication are agreed upon with the business and key stakeholders to prepare the user base.

Common go-live issues and how to preempt them

During the rollout of a Power Platform solution, a set of common issues may arise. Let’s look at the most common problems and how to identify them:

• Insufficient testing: A lack of testing may lead to areas of the Power Platform applications and integrations underperforming. A thorough test strategy and executing these test cases will help reduce the risk of the application failing to perform to specifications.
• Incorrect assumptions: These may be simple assumptions (for example, expecting the production user licenses to be in place on go-live) to more complex considerations regarding the connectivity to external systems and network access to on-premise services. A solid review of the cutover plan, including the distribution of responsibilities, will help reduce the number of assumptions that adversely impact the go-live plan.
• Missing rollback strategy: Without a defined rollback strategy, the business may find itself in a limbo state if the application go-live can’t be completed. Solution architects work with the business and system experts to define a solid rollback strategy, allowing the business to restore operations in the event of a fault during the rollout process.

Preempting rollout complications and de-risking the application go-live

Let’s understand the issues, as follows:

• Identify issues that will be present at go-live: Depending on the project timescales and delivery constraints, a Power Platform project may need to go into production before all the issues that have been identified during testing can be resolved. Identifying these issues and alerting users of their existence and when they are scheduled to be fixed will help reduce their impact on the production rollout.
• Perform a pre-deployment: Preparing the production environments and integrations ahead of time will help de-risk the rollout of the solution. Any component that’s prepared ahead of schedule will help identify issues in advance and provide more time for resolution. For example, a pre-deployment of the Power Platform solution may identify a problem with the available storage capacity, allowing more time to either clear resources or purchase additional storage.
• Perform data migration early: Data migration is often left to the later stages of the project. Performing early data migration test runs and running a mock production data migration before go-live will help iron out any issues with the process.
• Validate access for production users: Ensuring users have access to the production environment before go-live will remove one potential issue and de-risk the rollout of the application.
• Run the old and new systems in parallel: For Power Platform applications that replace legacy systems, the ability to run the old system in parallel will de-risk the rollout of the new application. Users can still perform their day-to-day tasks while the new application is brought online and users start moving to the new system.
• Automate the production rollout: Removing the scope for human error will further decrease the go-live risks. Whether through an Azure DevOps deployment pipeline or other means of automation, solution architects aim to automate the deployment of the following items:
  • User, teams, and business units
  • Reference data
  • User configuration
  • Data migration

Validating the solution before rolling it out to production

There are several tools available within the Power Platform framework that help solution architects validate the production-readiness of an implementation. Let’s take a look:

• Power Apps Solution checker: This tool is built into Power Platform solutions. It helps validate Model-Driven apps by checking the components within a Dataverse solution. The checkers validate processes, table configurations, plugins, and JavaScript web resources for deprecated functionality and development best practices. The following screenshot illustrates how the Power Apps Solution checker can be triggered:

Figure 15.6 – Using the Power Apps Solution checker

Solution architects aim to resolve all issues raised by the Power Platform Solution checker before deploying to production.

• Dataverse analytics: We discussed this tool in the capacity monitoring sections of this chapter. Dataverse analytics provides invaluable insights into the Dataverse APIs, allowing solution architects to spot areas that require attention before go-live (for example, spikes in API calls that may result in throttling of the application).

  Reference Documentation

  The following links provide additional documentation on the features within Power Apps Checker and Dataverse Analytics, respectively:

  https://docs.microsoft.com/powerapps/maker/data-platform/use-powerapps-checker

  https://docs.microsoft.com/power-platform/admin/analytics-common-data-service

Taking into account the Power Platform product release schedule

Power Platform receives regular maintenance updates and feature upgrades. As these updates are applied automatically, solution architects need to understand the impact they may have on a production environment.

Solution architects review the release schedule to ensure upcoming updates do not impact the rollout of an application into production.

Power Platform Release Schedule

The following document lists the Power Platform release schedule: https://docs.microsoft.com/en-us/dynamics365/get-started/release-schedule.

In addition to the release schedule, solution architects regularly review the upcoming Power Platform features and enhancements to plan for new functionality and deprecations.

Power Platform Release Plans

The following document lists the Power Platform release plans: https://docs.microsoft.com/en-gb/dynamics365/release-plans/.

To preempt go-live rollout issues, solution architects first apply upcoming updates to a development or test environment using the early access facility within the Power Platform application.

Power Platform Early Access Updates

The following document describes the options available for early access to Power Platform updates: https://docs.microsoft.com/en-us/power-platform/admin/opt-in-early-access-updates.

Running through the go-live checklist

The following checklist lists the various implementation milestones that must be completed before go-live can proceed:

Table 15.6 – Go-live checklist in action

Solution architects run through a readiness checklist, which can be used to inform a go/no-go decision.

The go/no-go decision

Product owners, key stakeholders, and the implementation team will typically meet before the cutover date to decide whether the solution is ready to be put into production. This decision will be informed by the go-live checklist. Depending on the outcome of the meeting, further work may be required to ensure the readiness of the solution for go-live.

Rolling out the production environment

Once the go-live checklist is completed, and the go-ahead is given to proceed to production, the solution is ready to be deployed. This section will discuss the various activities that are carried out by solution architects to ensure the successful completion of the Power Platform rollout.

The cutover

The cutover plan that was prepared in the earlier sections of this document is used during the actual rollout into production. With their deep understanding of the implementation, solution architects are well suited to help coordinate the rollout steps. The following table illustrates how a cutover plan might be checked through to completion:

Power Platform Go-live date: Date: 1st April 2022

Table 15.7 – Production rollout

Deciding when to roll back

Rolling back a deployment into production is typically a last resort. Let’s look at the reasons for initiating a rollback.

Unavailability of an external dependency critical to the implementation

Power Platform solutions may depend on external systems, and some of these dependencies may be critical to the normal functioning of the application. For example, a Power Pages application may depend on an external API to perform address searches or company lookups. Source systems may unexpectedly become unavailable, requiring the go-live to be postponed.

Unexpected deployment or migration errors

This could be the failure of a deployment or migration task that can’t be recovered within the agreed-upon timescales for the go-live rollout.

Under these circumstances, solution architects will work with the product owners to carry out the rollback and restore business operations.

Troubleshooting data migration issues

Solution architects work with the implementation team to identify and resolve data migration issues. Some typical data migration issues are as follows:

• Breaching the service protection limits:

High throughput may result in the Dataverse APIs being overrun, resulting in pushbacks from the platform’s service protection limits. A potential solution is to include the distribution of API requests across multiple license accounts.

An alternative solution is to change the data migration mechanisms by using data flows instead of direct access to the Dataverse API to import data.

Another solution may be to throttle the rate of imported data so that it works within the advertised limits or respect the pushback messages returned by the API when a limit is breached.

The following document details the service protection limits that may impact the capacity to import large amounts of data into Dataverse: https://docs.microsoft.com/power-apps/developer/data-platform/api-limits.

• Over-consumption of Power Platform request limits:

When Cloud Flows are used to import data, they consume billable actions. Breaching the licensed allocation of billable actions may result in the throttling of Cloud Flows. Depending on the configured retry strategy for these flows, they may fail to perform or trigger.

The following document details the API request limits and allocations that may impact the capacity to process large amounts of data:

https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations.

Handing over operational support

Once the Power Platform solution has been successfully deployed into production and the system has been validated as ready to go live, operational support is typically handed over to its IT support teams. The operational support guide discussed earlier in this chapter is used from that point onwards to service user queries, resolve user issues, and perform scheduled maintenance tasks.

The Power Platform solution is now ready for business-as-usual.

Summary

This chapter taught you about the benefits of a phased go-live versus the big-bang approach to production rollouts. You learned how to prepare a Power Platform implementation for go-live by defining a cutover process and a production readiness checklist. Finally, you learned how to proceed with the rollout into production, identify and resolve data migration issues, and hand it over to operational support.

You are now a fully versed Power Platform solution architect able to take a project from its conception through to completion.

The next chapter will help you prepare for the Power Platform Solution Architect Expert certification.