Stage 3: Production environment
The final stage of migration consists of two processes: Preparation, and final migration.
- Creating the “Production cut-over runbook”
- Deploying your application into the production environment
- Doing the “practice run” to migrate your data into the production environment
- Remediating issues that are found
- Testing your application with the “practice run” data
The final migration includes:
- Two-step data migration
- Synchronizing parallel development
- The final cut-over
Creating the "Production cut-over runbook"
It is important that the final part of this migration process affect your users for as short a time as possible. Pega strongly recommends that you create a “Production cut-over runbook” for the final migration, to determine what steps to take, how long each step will take, the expected downtime for users, and so on. This is separate from your overall Migration Project Plan, and should focus specifically on the cut-over process.
To determine these time limits more accurately, Pega will work with your team to do one or more “practice runs” or “dry runs” of data migration. The “practice” data migrations will give you and the Pega team an idea of how long the final migration will take, so you can use that information in your runbook. In addition, the practice migrations will check the connectivity during the data migration, ensure the tables are being copied and upgraded properly, and address any issues that may appear.
The migration of the staging data in the prior step will give the migration team a basic estimate for how long it will take to migrate your production data, but as the staging data is not an exact copy of production data, the team will fine-tune this estimate by doing the “practice run” with full production data.
Use the output of the “practice runs” to create your cut-over runbook, which should list in detail all the tasks and timings that will be required for the Production cut-over/go live. This runbook will provide visibility into exactly what activities will occur, and when, to ensure alignment for a successful go-live as you head into the final migration event. The runbook will also include the "backout plan" (should the need arise).
The cut-over plan should include a start date, and the time it takes from starting the migration to its full completion. It should also include:
- Proposed date and time of migration
- Amount of time to move the data
- Exact duration of the production outage
- Notifications to users
- Turning off rule changes
- Turning off creating new items
- Backing up rules
- Backing up data
- Identifying all database schemas and tables that require migration to your Pega Cloud Services environment
- Identifying all the people involved in this migration, and their roles
- QA testing levels to achieve before go-live decision is made
- Synchronization of parallel development
Work with your Service Assurance Advisor (SAA) and Migration Service Team to create your cut-over plan.
After you create the production cut-over runbook, the project team and key stakeholders (both at your company and at Pega) must review it for final sign-off.
Deploying your application into the production environment
After your application is running smoothly in the staging environment, use Pega Deployment Manager to move the application to the production environment.
"Practice run" migrating data into the production environment
“Practice run” data migrations are targeted to the production environment. Since there are no users in this Pega Cloud production environment yet, this step prepares for the final migration of the Production environment by doing one or more “practice runs” of your production system migration. These “practice runs” are performed to reduce the risk of this process and to ensure success when the final, actual migration to an environment with live customers occurs.
This data migration process involves copying from the production database you have in your on-premises system into the production database in your Pega Cloud Services environment. For the least risk, Pega recommends that you create a copy (“clone”) of your on-premises production database, so there will be no risk to the actual production database where your users are working while you perform a “practice run” for the migration.
For the actual production data migration during the cut-over, the real production source environment will be used.
Pega will perform the migration, converting your production data from your on-premise database copy to your Pega Cloud Services production database. The team follows your cut-over plan runbook to complete the data migration. This process provides you and Pega the opportunity to see how long the data migration takes, and to fix any data issues that may occur during the data migration.
If your company has been working in your Pega application for some time, there may be some data that won’t migrate smoothly. There may be data which contains variables from older versions of the application, where the variables no longer exist in the current version of the application, or other data issues. After a full or partial migration, you will need to review the records that did not migrate, and determine whether that data can be updated or otherwise fixed, or if this data should not be migrated. Perhaps you will need to remove some of these old records, or migrate them manually.
Your project team must work with Pega to determine the best way to deal with any data problems. Iterate through the migration process until the data migrates smoothly, and all the data issues are addressed.
Testing your application with the "practice run" data
After the "practice run" data has been migrated into your production environment without errors, Pega strongly recommends that you run a series of performance tests, to determine whether there will be any performance-related issues in your application.
For example, a new report might be incorrectly designed to display data from all the rows in a database table. In the development environment, with the test data, there may be 300 or so rows of data, which will work just fine for a report. But in production, there could be 2 million rows of data in that table, and that report would take a very long time to run and then fail. It is important to discover this issue before your users begin to use the application.
System performance has a direct impact on user productivity and business value. The accuracy and satisfaction of interactive users is affected by their perceptions of system performance and response time. See the Performance articles for details on how to ensure optimal performance for your applications.
As part of your Pega Cloud Services, you are given access to Pega Predictive Diagnostic Cloud. Use this service to monitor your application performance. For more information, see Monitoring your application using Pega PDC.
In addition to the performance tests, run all of your functionality, user, and other tests in this environment after you have completed migrating the “practice run” data. Since the production environment of Pega Cloud Services has a different production level for the applications (5 vs. 4 or less for the lower-level environments), and even stronger security, it is important to do a full round of testing in this environment before “go-live.”
Run all your tests, including the performance tests, in this higher-security environment. Your QA team should certify to your migration team that all your use cases have successfully passed testing before the final data migration into production, so you don’t run into issues after the cut-over.
Again, if you need to make changes to the application, you make these changes in the development environment. Then the changes must be tested in the staging environment, and finally moved to the production environment. Complete each move to the next environment using Deployment Manager.
After all the testing has succeeded, the final migration of data into the Pega Cloud production environment can occur. A go-live event for when the data migration occurs will be supported by the combined project team and executed in accordance with your production runbook.
Use the runbook to follow the steps for the final preparations before heading into the cut-over/go live event. This includes coordinating the availability and contact information for all required team members for the event, establishing a continuous communication plan for the event, and a final review and of the scheduled activities as described in the runbook.
When the go-live day arrives, enter a Cloud Change (CC) ticket for this step. Attach your “cut-over” plan as information for the list of required activities, personnel, and order of operations. Also note that your QA team must certify that all your use cases have successfully passed their tests before moving to production. The Pega Change Advisory Board will review and approve your service request.
Pega will use this CC to track the migration of your data from your on-premises production system to your Pega Cloud production environment. The team will set up a continuous communication call, perform the activities as planned in the runbook, and report on status throughout the event. The event culminates as you run a final application smoke test and make the Go or No Go decision to complete the go live and make the target Production environment accessible to users.
Two-step data migration
For the final data migration, Pega recommends a two-step process. In this process, the Pega migration team migrates most of the data to the target Pega Cloud Production environment at a specified date which is a few days or so prior to the go-live date, and then the team migrates the data “delta” (data that is created during or after the bulk migration) during the “cut-over” process.
This process is meant to shorten the “outage” time period for your users. For example, if your data migration tests have shown that the migration process will take 10 hours, then moving all the data up to “last Sunday” means that your users can continue to work in the old system while the bulk of the data (say, 9.8 hours) is migrated. Then the users can be closed out of the system for only 20 minutes (rather than the entire 10 hours), while the data that was entered since “last Sunday” is migrated.
Synchronizing parallel development
Up to this point in the migration process, your users have continued to work and create new cases in your “old” on-premises Pega application. This means that rules and data have probably been created or changed; this parallel development must be synchronized with the Pega Cloud Services application.
Just before the final data migration, changes to rules and data in the on-premises system must be disallowed, in order to “freeze” the application. Any changes that occurred since the original upgrade must now be made in the Pega Cloud Services development environment, tested, migrated to Staging (using Deployment Manager) and tested, and then moved into the production environment and tested.
After the bulk of the data has been successfully migrated, development in the old system has been “frozen,” and the parallel development has been synchronized, all access to the on-premises system must be shut off – all users must be locked out of that system. The Pega Cloud Services team will migrate the “delta” changes (from the date of the bulk data move to the present) from the on-premises production database to the Pega Cloud production database.
Run your final tests in the Pega Cloud Services production environment, and then make the Go or No Go decision to complete the go live and make the target Production environment accessible to users.
After the completion of the go live event, Pega will continue to closely monitor and support your new environments, verifying your satisfaction with your new Pega Cloud service.