Important considerations for downtime-optimized conversion project
To plan a downtime-optimized conversion project, different aspects are important to consider. First of all, it is important to consider a database migration with Database Migration Option (DMO). It is recommended to utilize DMO even if the source database is already SAP HANA.
Summary: Differences of downtime-optimized conversion with and without database migration
| with DMO | without migration | |
|---|---|---|
| Transfer | migration | copy2shd |
| Large table selection for uptime migration | possible | not applicable |
| Features | all features such as uptime Customizing for FI Conversion and execution of XPRAs in uptime | some features not available |
| Reset via Software Update Manager user interface | always possible | possible until "start of downtime dialog" (after that, a restore is required) |
For utilizing and optimizing the downtime-optimized conversion, several log files are relevant.
Summary: Relevant Files
- <customer_buffer_doc>
- Customer buffer file containing at least the finance (FI) customizing transport request (file name arbitrary).
- ZDIMPANA.ZIP
- Statistics data from production system, relevant for impact analysis and for table selection for uptime migration (if migration applies).
- MIGRATE_DT_DUR.XML
- Migration durations per table from previous run (if migration applies), relevant for table selection for uptime migration.
- <tables_list.txt>
- List of table names for uptime migration (db migration case) (file name arbitrary).
- UPGANA.XML
- Software Update Manager procedure statistics from previous run - for example, for Technical Downtime Optimization app.
- APPLANA.XML
- Statistics from FINS_MIG_STATUS run, for example, for Technical Downtime Optimization app.
With downtime-optimized conversion, additional tasks not only for technical execution, but also for application colleagues are required. Those need to be communicated and practiced early in the project.
Summary: Important Tasks for Application Colleagues
- Create "clean" FI customizing on a sandbox after a standard conversion run.
- Apply Asset Accounting activities in Software Update Manager uptime.
- Handle issues in finance conversion (FINS_MIG_STATUS) in uptime and downtime.
- Follow hard freeze requirements listed in guide.
- Consider restrictions listed in excel list attached to SAP Note.
- Follow FIN customizing freeze requirements.
- Prevent mass load activities during replication.
Planning a Downtime-optimized Conversion Project
The overall project planning of downtime-optimized conversion will include standard conversion runs for those systems for which downtime is not relevant, like sandbox (SBX) , development (DEV), and potentially quality assurance (QAS). In addition to the downtime-optimized conversion run on production (PRD), you will have to execute test runs for this approach on copies of production to get familiar with the approach.
Especially important to consider is the need for an initial standard conversion run to create the FI customizing transport. As discussed in Unit 2, the standard conversion run typically is executed on a sandbox which is a copy of production. The resulting customizing transport can be verified in another sandbox run utilizing downtime-optimized conversion approach. System, that are not that downtime-relevant use the standard conversion approach. When reaching the last run before production, which may be another sandbox for dress rehearsal, a load verification including downtime execution on a clone, or the quality assurance system, it is important to freeze the customer buffer to validate a production-like state. One exception may be the FIN customizing that can be adapted during the run via customizing on temporary instance.
Hint
The following image shows an overview of project test runs. It includes the load verification in the specification of using a clone (that is, including execution of downtime on a clone). You can see four test runs for the approach:
- Sandbox
- Quality Assurance
- Load Verification
- Dress Rehearsal
Based on project experience, we strongly recommend to follow that plan. Technically, fewer test runs are possible, but would increase the risk.
To plan these runs on a timeline, several aspects are important to consider:
- Proper planning of standard and downtime-optimized runs.
- Early announcement and alignment about customizing freeze.
- Prevention of mass load activities on production during replication.
- Planning and coordination of Asset Accounting activities in Software Update Manager uptime.
- Clarification on Load Verification run.
- Consideration of Delta Load (including downtime execution on a clone) approach.
Last, but not least, another example from a real project that highlights the downtime savings leveraged by downtime-optimized conversion. All the best for your project(s)!
- Source: SAP ECC 6.0 EHP8
- Target: SAP S/4HANA 2020 FPS02
- Database size: 7 TB
- Technical downtime: ~40 hrs
- Reduction of technical downtime compared to a standard run: more than 42h or 51%
