cancel
Showing results for 
Search instead for 
Did you mean: 

Unicode Conversion Methods

Former Member
0 Kudos

If any one can help me in understanding the Advantages & Disadvantages of Two sever method and Having a Parallel landscape for Unicode , would be helpful

Current Landscape : DEV,QAS,PRD

a) Two server method : SBX for Copy of PRD , SBU for Unicode conversion . No Parallel landscape

The Movement you convert your DEV to Unicode , DEV is Unicode and QA is non-Unicode and PRD as well.

Is there a risk here?

b) With a Parallel landscape NEWDEV,NEWQAS,NEWPRD

Can we use the NEWPRD for mock ?

a) Mock -NEWPRD can be used as SBX for Mock and NEWQA can used as SBU for Unicode conversion

b) DEV-> Copy DEV NEWPRD (SBX) and use NEWDEV as SBU for Unicode conversion

c) QAS-> Copy PRD to NewPRD(SBX) and Use NewQAS as SBU for Unicode conversion

d) Rehearsal Export from PRD and Import in NEW PRD with Unicode kernel

e) PRD-> Export from PRD and Import in NEW PRD with Unicode kernel

What is advantage and disadvantage/Risk in the above two approaches

Accepted Solutions (0)

Answers (1)

Answers (1)

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Deepak,

a) this is possible (SBN is used for copy and for export; Import is done on SBU). It is not absolutely necessary to use on DEV and QAS the two server method (of course also depending on your downtime and hardware requirements on those systems). Test of the two-server-method can be done on Sandbox systems.

b) There is no need to build up a parallel Unicode landscape (although this is of course possible if you want to test extensively). Even if you purchase new servers for DEV and QAS, the standard conversion would result in a restricted period of mixed landscape (e.g. DEV is Unicode and QAS is non-Unicode). For restrictions in this case please have a look at SAP note 1322715 point 9. and 14. and .

The new server for the PRD system can be reused for SBX conversion.

Best regards,

Nils Buerckel

SAP AG

Former Member
0 Kudos

Dear Nils

Basically What Iu2019m try to understand is that

If my Project time lines are 5 months

3 Weeks for Mock

4 Weeks for DEV because ABAP Remediation and Unit Testing are involved

5 Weeks for QA because Functional Testing , UAT, UAT fixes are involved

1 Week for Rehearsal

Cutover& Go live on weekend

What is the Risk & advantage for

A. One Server Method : If the customer says he will upgrade his current hardware and will not buy a Target Hardware for DEV,QAS,PRD however will provide Only one TEMP Server available equivalent to PRD , What are the risk associated

1) What I could think is Code free of 7 weeks

2) Longer Export and Import Times as Export and Import or Sequential

B. Two Server method : AS shared in by you the SAP Unicode Document System copy to SBN (NUC) . SBN to SBU (UC).

Advantage is Parallel Export and Import will happen

Risk ?

Iu2019m trying to see which approach has more risk . Hope you can help me now

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Dear Deepak,

A 1) as stated before, in most cases I do not see a hard development freeze here.

A 2) This is correct - longer downtimes must be accepted in this case

In addition it is not possible to directly compare Non-Unicode and Unicode (after the PRD conversion) - as the Non-Unicode system is not available anymore.

B) Yes, main advantage is the reduced down time. In addition if the Non-Unicode system is still available, this can be easier used as fallback in case the Unicode conversion fails.

Overall the decision highly depends on the system, which should be converted. If you have a small single code page system with lower downtime requirements, the one-server-method might be applicable with a low risk.

However if you have a large system and/or an MDMP system and/or hard downtime requirements then I would recommend to use two servers.

Best regards,

Nils Buerckel

SAP AG

Former Member
0 Kudos

1) If you are planning to do a sequential export/import and use the same hardware . All that you need if space for the export dump. However if the client is ready to give you a temp server you can copy the Source to the temp and use it later for comparison /fallback if needed. Incase the export dump gets corrupted/unusable you can immediately start the export from the Temp server. You have to plan well when you hit production. Take a full file system backup of the PRD system before you start Unicode export , probably restore the backup to the temp and you use it as fallback if things go wrong.

For mock you can copy PRD to the temp server and perform the Unicode conversion there .

Remember if your Production is a HA system beware of issues/suprises that might come up during PRD conversion.

2) Parallel landspace is a very safe approach and can reduce downtime to a great extent. Your DB size would greatly influence downtime.

So from what you have explained earlier you would be copying PRD- SBX and Parallel export/import to SBU. In that case

u2022 How are you planning to move back to PRD from SBU. You have to spend time on a system copy and modifying the SAP profiles/environment etc which can be time consuming.

u2022 Else isolate the target system from PRD but let the target SID be PRD(instead of SBU) in that case once you complete your Unicode conversion you just need to restore the Unicode converted system back to the original system. Since the SID doesnu2019t change it will save a lot of time .The only change would be the host name so you have to make that change in the profile.

Else leave the target unicode converted system as it is and decommision the current PRD server. However you to make sure all your interfaces are pointing to the right hosname. So you might need to simulate that in advance and perform a interface testing.

All the best

Gerard