Data migration: Cut

The cutout describes the period during which the production system is prepared for the commissioning of the new system. This included technical preparation of the source and target system, data migration and business transition.

Transition describes the business activities carried out to support the transition from one system to another, for example:

• Information about customers and suppliers;
• Latest clean-up activities like P.O. closing or production orders as well as month-end closing activities;
• Preparation of the interim period without support from the previous system;
• Inventory movements in order without system support;
• Relabelling warehouse storage locations;

Outage planning

The basis of the transition plans are the migration discussion plans, including all manual technical activities for data migration. In addition, the plan should include:

• Company transition activities;
• Points for ‘go’ or ‘no-go’ decision;
• Fallback strategies;
• Communication plan;

During the implementation phase, a changeover master plan will be created which will cover all changeover activities within the framework of the harmonization project. This changeover master plan will be adjusted to the specific deployment activities for each deployment.

Approval procedure

The same principles apply for loading production data as for test migrations.
All business checks are based on live data, displays made during testing have a direct impact and cannot be reversed. Regression testing for personalization is described in the Functional Analysis Testing Strategy.

Since the scope of data migration for the transformation program only includes adding data to the new system, no regression testing on data from sites already in the transformation system is necessary.

The execution of the cut

While executing the transition, detailed condition monitoring and clear communication is required. To support this, transition status meetings will be organized. The meetings will be led by the interim manager; participants will be project managers, business representatives and other relevant stakeholders.

Approximate schedule

The migration transition plan can be roughly broken down into the following steps (examples of activities are mentioned for each step):

• Company
  • inform partners
  • end of operations
  • objects of evaluation of costs, proposals and prices
  • Clear / Close open documents for each item
• Preparing and cleaning data in the old system
• Preparing for data migration
  • Value mapping
  • Matching types of fields
• System preparation
  • Users and authorization management
  • Interface design
  • Record ranges and their criteria
  • Customizing data type controls by fields
  • Disable notifications in target system to avoid email overload
• Sales activities in final transition to the old system
  • Closed periods, open positions, etc.
• Block the old system
• Data migration
  • Basic data
  • Release the old system for migration
  • Old system monitoring reports
    • For example: comparison of stock level, income statement, income statement, number of contacts, etc.
  • Transactional data
  • Approval migration
• Final preparation of the new system
• New system released for normal business

Between crashing the legacy system and exiting the production system, no normal daily activity is possible.

The data essential and necessary for the failover plan comes from the migration tests before Go Live. Dependency checks can influence the runtime calculation and can be obtained from migration testing under commissioning conditions.
Based on this information, an accurate, secure and ‘close to reality’ transition plan for final production release can be developed at the end with an estimated runtime calculated for the expected volume of data from the system. production. Weak points, resource bottlenecks, etc. can be avoided with this procedure.

With this detailed and reliable changeover plan, production system downtime can be easily estimated. The detailed changeover schedule should be defined as part of the deployment project.

Cut off with the old system

For existing systems, there will be cut-off points defined. The cutoff defines the point where activities of the legacy system are stopped, no data is created or modified, and no further publication is made to have a stable basis for data migration.

To support cutoff, the relevant permissions should be reduced to “view only”.

There are 2 possible scenarios:

1. Some divisions of your company remain in the old system
   1. The shutdown is limited to organizational units that will be migrated to the new system. The remaining organizational units can continue to work.
2. No divisions remain in the old system
   1. The cutoff is valid for the entire system.

Current system downtime

To allow rollback in the event of serious errors during migration, business activities must be stopped in the system.

Downtime begins just before the start of data migration. It needs to be announced well in advance (several weeks) to allow live sites to prepare for downtime.
Downtime does not end until after the final start-up decision is made by the deployment leadership at the transition status meeting.

When planning downtime, allow enough time for a possible rollback after the final decision to launch the new system for normal business.