UPDATED Mar-2025

Management of environments and releases in the cloud is an important task that begins at the very start of your project and continues through the life of your cloud service.

Your initial subscription includes:

one production environment
one test environment
You may purchase additional test environments (ATE’s) depending on the complexity of your project.

Planning your environments

Deployments may be big bang or phased rollouts.  A phased rollout may be by geography or business process. Regardless of your rollout approach, you should carefully plan how to use your non-production environments during the life of your cloud service.

Work through environment planning early in the implementation. This helps you determine the different activities you will do in each environment, the duration of the different activities, the hand offs required and overall helps set up your project for success.  Additional information can be found here.

Consider Maintenance

Quarterly Maintenance

Oracle releases new features and functionality every quarter.  We apply updates to all your environments once per quarter.  You will get updates on one of these schedules:

  • Cohort A:    Feb-May-Aug-Nov
  • Cohort B:    Mar-Jun-Sep-Dec
  • Cohort C:    Apr-Jul-Oct-Jan

Quarterly updates cannot be skipped or rescheduled.  These updates must be on your environment plan for visibility.  

You always have two weeks to test a quarterly update.

  • 1st Friday of the month – non-production updates
  • 3rd Friday of the month – production updates

For your specific update dates, check your notifications and the Oracle Cloud Console.

For more details on quarterly updates, see Harness the Business Value of Quarterly Updates.

Concurrent Maintenance

Concurrent maintenance allows you to maintain non-production and production environments at the same update level at the same time.  We offer two options depending on where you are in your cloud services journey:

Concurrent Maintenance – Nonproduction: Optional concurrent maintenance is available to customers during implementation.  Your production environment would receive the quarterly updates at the same time as your non-production environment. All your environments would be updated on the first Friday of each month (except Middle East which receives on Thursdays). This offers many benefits:

  • the ability to request environment refreshes during black-out periods
  • getting exception updates applied faster in all environments for critical issues 

Concurrent maintenance – nonproduction must end the month prior to go live.  

Concurrent Maintenance – Production: After your initial go-live you may choose to have one of your non-production environments get the quarterly update on the same cadence as production.  By designating one stage environment to receive updates along with production, this ensures you have one environment for issue resolution that is at the same update level as production.

For additional information, refer to Oracle Fusion Applications Cloud Concurrent Maintenance Option (Document ID 1646394.1).

Environment Refresh Requests

There are two different types of environment refreshes available:

  • Production-To-Test (P2T): From a production environment to a non-production environment
  • Test-To-Test (T2T): From a non-production environment to another non-production environment, for those customers with multiple non-production environments

Refresh requests are now done via self-service from your Oracle Cloud Console.  We recommend that you plan your refreshes carefully and to ensure your environments are in sync.

Blackout dates

You cannot request refreshes during blackout periods.  Blackout periods are between quarterly updates.  This is when source and target environments are ‘out of sync.’  The blackout period is from 4 days before to 1 days after a quarterly update.  Therefore, you want to request your P2T/T2Ts outside of that window.  There are other times when you may fall into a blackout period based upon your configuration and environments. For additional information, Oracle Applications Cloud Service Definition – Environment Refresh: Doc ID 2015788.1 or Refreshing an Environment.

Building your environment plan

Start early and iterate often.  You want to begin planning as early in the project as possible and not allow this plan to get out of date.  The more planning you do, the more success you will have.

As you plan your environment usage, you may consider organizing like activities in consistent environments.  Some of the different environment usages:

  • Development – all your development objects are written, and unit tested in one environment.
  • Gold – once you are ready to finalize configurations, you would add them to your gold environment and that becomes the environment that is copied down for future refreshes.  This is often your production environment before your first go live.
  • Pre-production – once a phase is live, you want an environment that looks as close to production as possible.  This environment will have frequent P2Ts, and the update level will be consistent to production for testing production issues.  Having this environment will make it easier to investigate, diagnose and address issues encountered in production. 


What to include

Organize your environment plan by environment.  You will include the following types of activities:

  • quarterly updates for test and production and associated blackout periods
  • production to test refresh (P2T), test to test refresh (T2T)
  • data conversions
  • development (including build, test, and deployment)
  • configurations (test and gold)
  • testing cycles (SIT, UAT, performance testing)
  • testing of runbook (ERP Period Close White Paper with Runbook Considerations (Doc ID 2506148.1)
  • dress rehearsals
  • production prep and cutover
  • project milestones
Excel diagram showing each environment with planned tasks by week/month
The above diagram represents various activities to be planned for your project.  It is not meant to be an actual project timeline.

 

Excel diagram showing each environment with planned tasks by week/month after initial go-live
This second diagram represents the second phase of your project where your test environment is used for production support.
 

The above diagrams represent different phases of your project.  The first image is your initial phase where you do not have a live production application.   Once you have a go live, you want to transition one of your environments to a ‘pre-prod’ environment.  Refresh this environment frequently so it is as close to production as possible.


Key to success

When creating your environment strategy consider the following:

  • Be thoughtful with each environment and plan it for specific activities.  For example, an environment for development, a different environment for Conference Room Pilots (CRPs) and functional testing, maybe a separate environment for mock data conversions, integration testing/unit testing.
  • Coordinate across project phases for maximum efficiencies (reduce updating configurations in multiple places, migrated code multiple times)
  • To ensure updates are applied across your solution in a timely manner, plan early for regular refreshes (P2Ts, T2Ts). Also, consider blackout dates explained above.
  • Ask questions, iterate and maintain this plan throughout your cloud journey.

Additional Information

For additional information, see Support note 2848566.1.

Conclusion

Environment planning is critically important to your successful implementation.  Thinking through the moving parts on your project and taking the time to plan them out will save you many headaches downstream and will mitigate possible future project issues.