Cutover disaster recovery

[former_member663772]

Hi all,

This question is specific to the scenario of a cutover in a IS-utility (fall back strategy). The scenario is: consider a utility compnay going live on ISU. The SAP ERP was already running in the company. The thing is when the company starts to bring ISU to go live they want to run ERP integrated with ISU in the same server machine.Thus they have to close ERP system for the period when ISU is going live. The time when they go live after migration some un-forseen circumstances make the ISU cutover go bad. Thus they have to close ISU for now and rewoke ERP again until they figure out a way out of the problem.

My question is when we are migarting using emigall/ISMW we are running the objects in create mode. If the cutover went bad and the only change to the ERP is the migrated objects of ISU, in order to reverse the migrated data can we run the objects of the same migration file under delete mode. Will this make the ERP go back to what it was before migration?

waiting for your answers

[Former Member]

I suggest you create a parallel production environment as a copy of the current ECC at a certain point in time. After you do all your migration, apply the deltas to the new production box and then switch the production environment to the new box, if everything goes well. The advantage will be that you don't have to bring down your production server for a long time except for the copying and switchover. Another advantage will be that if your migration doesn't go well, you can trash the new environment and start all over depending on how bad your migration went.

[former_member663772]

Thanks for the reply

The stratgey you suggested Mr Adavi is the one with the machine segrigation. I get that, for that purpose we will take a snap shot of the ECC system and use it in case of fall back. But the emphisis was on the emigall solution. Will the migated data, when deleted by emigall objects be gone and make the ECC as if it was not migrated or changed?

[friedrich_keller]

Hello Hashmi,

Let me first try to answer your technical question: "can we run the objects of the same migration file under delete mode": I'm afraid but there is no option to explicitely delete data in just switching a flag to delete mode. Please don't get confused by the work mode (processing type) field that is available on the migration object maintenance screen. Basically, this field controls how the oldkey is managed within the KSM.

As a consequence, you will have to think of either a correction of migrated data or a restore of the original system as a reliable fallback strategy when you find out that something went wrong. It can be imagined easly, that an incomplete data reconciliation and data validation process as part of the migration exercise can lead to catastrophic consequences for the company if problems are found out after the first business processes have been executed after go-live - in particular after posting financial documents. It will be extremely difficult to recover.

Recommendation: always execute at least 2 full dress rehearsals followed by a limited integration test to test the migrated data prior to going live. This is the highly recommended risk mitigation strategy. Anything else I regard as reckless.

Kind regards,

Fritz

[former_member663772]

Thanks Fritz for the clearification.

One last thing, if we mark all the master data as delete flag (cuz i dont know exactly how you mark transactional data in delete flag) and then run archiver 'sara' will it delete the IS related data then.

[friedrich_keller]

Hashmi,

I don't think that this is a viable solution. First you cannot makr all migrated as to be archived such easily and sometimes you might even harm the consistency and integrity of the (reminaing) data. Worse, IS-U is a solution that integrates with many other core modules. It will be quite difficult to pull just IS-U data out (i.e. think of MM and PM data nd processes). Will you have the time to mark all objects and run archiving?

And what about all the transport requests you put into the production box? There is no way to pull them out except with a restore,

Once more: test, test , test, and test once more prior to going live!

Cheers,

Fritz

[former_member663772]

Once more Fritz thanks

Just one thing i would like you to comment on is the answer stated by Adavi above of the seperate server strategy (parallel production environment). Does that apply for the scenario of Cutover Fallback?

Edited by: F.Hashmi on Jan 25, 2011 7:09 PM

[friedrich_keller]

Hello Hashmi,

Srini said: I suggest you create a parallel production environment as a copy of the current ECC at a certain point in time. After you do all your migration, apply the deltas to the new production box and then switch the production environment to the new box, if everything goes well. The advantage will be that you don't have to bring down your production server for a long time except for the copying and switchover. Another advantage will be that if your migration doesn't go well, you can trash the new environment and start all over depending on how bad your migration went. 

In brief, I tend to disagree to having the production system in production with write/change access while doing data migration into a shadow (migration) system since (allmost) all changes done in production must be applied manually in the migration system. The question is if this is possible at all. In contrary, it won't be possible to apply changes of the shadow system (as a result of data migration) to the production system. In addition, don't forget, that copying in Srini's sense is not exactly copying data.

One last point: many basis teams are afraid of restoring the production system hence trying to defeat such an idea. Why? Well, because the have never tried this before. But wouldn't a restore a good fallback strategy?

Cheers,

Fritz