Two Major News with SUM 2.0 SP 17

[Boris_Rubarth]

Hello SUM fans, this blog is a bit long and full of text, but it's worth reading, as we have great news!

1. Homogeneous option for DMO

SUM 2.0 SP 17 (available as of May 26th 2023) offers a homogeneous option for DMO!

Until now, DMO was always heterogenous: the database type was always changed, for example from DB2 to SAP HANA DB. Now, for the first time, SUM allows a homogeneous migration from SAP HANA DB to SAP HANA DB.

But this comes only for specific cases:

• Only SAP HANA DB to SAP HANA DB is supported
  (no plan to offer homogeneous DMO for other database types)


• Only target product SAP S/4HANA is supported
  (target "SAP ERP on SAP HANA" is not supported)


• Some restrictions apply for schemas and partitioning
  (documented in SAP Note 3296427 on DMO)


• doDMO and doC are not (yet) supported for homogeneous DMO
  (plan is to support this with a later SUM SP version, maybe SP 18 in October, or later)
  (with SUM 2.0 SP 17, we accept pilot projects for homogenous DMO with doDMO or with doC)

1.1. Main Use Case

So, "DMO with system move" allows SAP HANA to SAP HANA migration. The main scenario that benefits from this new feature is the combined conversion & transition:
convert "SAP ERP on SAP HANA DB" to SAP S/4HANA and transition the system to SAP S/4HANA Cloud, private edition (or any hyperscaler) in one step.

Up to now, this was a 2-step approach:

Now, it is a 1-step procedure:

(The illustrations are based on the PCE documentation: Transition Paths | SAP Help Portal)

1.2. Further use case

Another scenario that benefits from this new feature is the transition of an existing SAP S/4HANA (on-prem) system to SAP S/4HANA Cloud, private edition.

• Either upgrading to higher SAP S/4HANA release


• Or keeping source product version level, combining it with „DMO without system update“
  
  
  
  • For this, backup/restore or HANA tenant copy is probably the easier approach
  
  
  • Keep in mind that with any DMO scenario, the System-ID of the source system will generally be kept
  
  
  
  

1.3. Minor further use case

The option can also be used purely on-premise for a change of the SAP HANA database during a conversion from SAP ERP on SAP HANA DB to SAP S/4HANA. Like starting SAP ERP on SAP HANA 1.0 and omitting the separate SAP HANA upgrade to SAP HANA 2.0.

1.4. Overview on new scenarios for "DMO with system move"

The illustration shows the main use case in the middle, the further use case above, and the minor further use case left hand side with a dotted line. All three cases are listed in orange. The thin blue lines on bottom indicate the already existing use case for "DMO with system move" from non -  SAP HANA DB on source.

1.5. Further information

• SAP Note 3296427 for DMO with SUM 2.0 SP 17
  (sections on "Homogeneous database migration")


• DMO Guide for SUM 2.0 SP 17
  (sections on "Homogeneous database migration")

2. DMOVE2S4: "DMO move to SAP S/4HANA (on hyperscaler)"

2.1. Alternative to "DMO with system move"

For the combined conversion & transition, until now only "DMO with system move" was available and used for projects. Disadvantage is that the approach does not allow downtime-optimization techniques like downtime-optimized DMO (doDMO) or downtime-optimized Conversion. Now with SUM 2.0 SP 17, the DMOVE2S4 approach is available as an alternative to "DMO with system move" - under specific conditions (described below). It allows to use the plain-DMO (plain in the sense of "not-DMO-with-system-move") for the conversion and transition to a hyperscaler.

Note: you may have heard about this approach already, but with other names: "DMO to Azure", or "DMO conversion to hyperscaler".

2.2. Advantages

• Proven SUM technology is used
  (not brand new coding)


• Approach works for source systems on anyDB as well as on SAP HANA DB
  because SUM now allows homogeneous migration (SAP HANA DB to SAP HANA DB, see section 1 above)


• DMOVE2S4 can be used as is, or additionally with downtime-optimization techniques
  like doDMO, or doC (but currently only if source is on non-SAP HANA DB, see section 1 above)


• R3load pipe mode is used, not file mode
  so no dump files are created like for "DMO with system move"

So the approach comes with three potential usages / flavors:

• DMOVE2S4 (plain)
  DMOVE2S4 with downtime-optimized DMO
  DMOVE2S4 with downtime-optimized Conversion

2.3. Main steps of approach

1. Install AAS in target
   In the target environment, in which the target SAP HANA DB is installed, you install an Additional Application Server (AAS) which belongs to the source SAP ERP 6.0.


2. Extract and start SUM on that AAS
   You start SUM for the conversion on that AAS host in the target environment.


3. You confirm the "ACSC instance move" offered by SUM
   As SUM detects that it is not running on the Primary Application Server (PAS) host, it offers the ASCS instance move. This will install the ABAP central services on the AAS in the target, and the previous PAS will not be started again after downtime.


4. Post-activities
   Some post activities are required which are described in the DMO Guide, like moving the directories sapmnt and trans to the hyperscaler.

Although it is not listed here, it is important to enable the required communication between the source and target environment, like opening ports.
The whitepaper "Converting from SAP ERP on Premise to SAP S/4HANA on Microsoft Azure" (listed below) explains those steps in detail, for the case of target hyperscaler MS Azure.

Note that the "ASCS instance move" will move the ASCS instance to a host on which an AAS is running. If the source system had the ASCS running separately from any Application Server Instances, this setup will not be restored by SUM (see blog post  https://blogs.sap.com/2019/04/12/ascs-instance-move-use-sum-to-switch-your-ascs/). It is of course possible to afterwards manually create such a setup. In case of a transition to "SAP S/4HANA Cloud, private edition", the AAS is anyhow installed (by the executing partner) on the "migration server" which is provided by SAP (ECS). After the partner has finished the conversion run, the migration server will anyhow be dismantled.

Note on point 1: Install AAS in target [added on June 16 2023]
The OS of the AAS host has to be supported, e.g. for MS SQL database, it must run on Windows. You should check if the target environment supports that OS.

Note on point 3: Confirm "ASCS instance move" [added on July 6 2023]
If your ASCS instance is not yet running separately on your source system, SUM will automatically execute the "ASCS instance split" (see SUM guide: ASCS Instance Split | SAP Help Portal). The new ASCS instance will then be created on the AAS.

2.4. Approach is not a SUM option

Note that the DMOVE2S4 approach is the appropriate combination of SUM features and option, but it is not an option which is offered by SUM. The SUM is not aware if it is used for the approach, and will not show this for example in the title of the browser window. This is different to "DMO with system move" which is a SUM option, and which is shown on the SUM browser page.

2.5. Prerequisites and conditions

• DMOVE2S4 is only supported for target SAP S/4HANA


• It is supported if the technical requirements are met (actual values are listed in SAP Note 3296427 on DMO with SUM 2.0 SP 17)
  
  
  
  • Latency < 20 ms
  
  
  • Bandwidth > 400 MBit/s
  
  
  
  

Note: SUM runs a latency check (result is visible in DBSTAT.LOG file). For higher latency values, a warning is shown in log file CHECKS.log. The latency check is executed for conversion with migration and for an SUM "extended prerequisite check" (with target database).

2.6. Further information

• DMO Guide: DMO Move to SAP S/4HANA (on Hyperscaler) | SAP Help Portal


• SAP Note 3296427 for DMO with SUM 2.0 SP 17
  (sections on "DMO Move to SAP S/4HANA")


• White paper: "Converting from SAP ERP on Premise to SAP S/4HANA on Microsoft Azure":
  https://www.sap.com/documents/2021/12/a8fcb608-097e-0010-bca6-c68f7e60039b.html


• Initial blog post in SAP Community: “DMO to Azure”: combine SAP S/4HANA conversion with the move to Azure (without “DMO with System Move...

2.7. Illustration

The illustration shows both options for a combined conversion & transition.
Note that DMOVE2S4 requires target product SAP S/4HANA, different to "DMO with system move".

So if two options are available, which one to chose?

• First question is whether the latency and the bandwidth are good enough for DMOVE2S4. If not, then "DMO with system move" is to be used.
  
  
  
  • Only if conditions are met to use DMOVE2S4, then the second question is:
    is downtime optimization required? If yes, then DMOVE2S4 is the right choice.
  
  
  
  

Boris Rubarth
Product Management SUM, SAP SE

[chrymt]

Thanks Boris for this wonderful blog!!

So homogeneous DMO will be only advantageous when the target is S/4HANA PCE. Is there any use case when the target is S/4HANA foundation?

[Boris_Rubarth]

Hi Amit,

if your question is whether systems based on SAP S/4HANA foundation are supported, the answer is yes, as listed in SAP Note 3296427 for DMO with SUM 2.0 SP 17.

If your question is if I have an example for such system: "SAP Transactional Banking for SAP S/4HANA" is based on SAP S/4HANA foundation.

Regards, Boris

[chrymt]

Hi Boris,

Thanks for your response.

My question was whether there is any use case of homogeneous DMO where target is S/4Hana Foundation.

[hasanbacioglu]

Hi Boris,

Great news.

I have 2 questions.

1-)

This part is confusing for us. Can we use DOC as fully documented in ADM329 exactly the same way? FIN and ML data conversion moved to uptime processing? Or else, is the only benefit use of memory pipe?

2-) Is latency < 20 ms a strict requirement? Can we give it a try with a latency of say 30, 35 ms?

Do you have any benchmark, guiding results about success rates with higher latency in your pilot projects?

Thanks in advance for your kind attention and response.

[Boris_Rubarth]

Hi Hasan,

1. Not sure where you have copied that text (with the highlights in red) from.
   Either you use DMOVE2S4 for a standard conversion,
   then all pre- and post activities are like in a standard conversion.
   Or you can use DMOVE2S4 for downtime-optimized Conversion (doC),
   then all pre- and post activities are like in a doC-run.


2. As listed, SUM only shows a warning, but you can proceed to give it a try.

Kind regards,
Boris

[hasanbacioglu]

Thanks your superb and prompt response.

You are the best.

It is copied from (page 23)

Software Update Manager 2.0 SP 17 (including Database Migration Option)

Conversion to SAP S/4HANA Syseems using SUM: ABAP Systems on Windows

Version 1.0 2023.05.26

Kindest Regards,

[former_member860962]

Hi Boris -

 

Thanks a lot, great info!

 

Quick question - Regarding DoC with HANA Database already in place, as per your info this is still in the pilot phase. Is this "pilot" phase available only for SAP to perform, or can also be done by other system integrators?

In our case, we do have a big client having ECC on HANA (10TB) where the requirement is to do the conversion within 48 hours. A bit difficult to do it with standard approach.

The project start date is August, hence is no time left to wait for SUM 2.0 SP18.

Could you please advise?

Thank you and best regards,

Radu

 

[Farid]

Hello boris.rubarth

I assume that if the source system is SAP ECC6, on SQL Server  DB and Windows Application servers then ...DMOVE2S4 is not an option, right ? As running a Linux AAS would not be supported by SAP ?

[Boris_Rubarth]

Hello Raoul,

as you state correctly, an Additional Application Server (AAS) on Linux is not supported for a system based on an MS SQL database. So in this case it is required to have the AAS on Windows.

You may contact the SAP ECS colleagues to clarify if an exception is possible to have an AAS on Windows.

Regards, Boris

[Aneesh771]

Hi boris.rubarth,

 

Can you please provide some thought on using the SID during the SUM DMO migration ( system move option ) .

For Eg : the PRD environment , we are using DEV->QAS->PRD . For the  DMO with system move option , what is the sap suggested method for SID . Do we need to use the same or Different one. if the we are using  same what is the advantage are we going to get with this?

Thanks in advance for the support.

 

 

[Boris_Rubarth]

Hi Aneesh,

for all migration scenarios with SUM, the System-ID is kept, so no choice to change that.

Kind regards, Boris

[Aneesh771]

Thanks boris.rubarth for the quick reply. during the migration we need to use the same SID( both on-prem and cloud with system move option).

Just an eg : for the migration, we copied system from the PRD landscape and use different SID than production( just EG : ABC is the PRD SID and XYZ is the copied system SID for the migration and upgrade) . for the target we will use the same SID : XYZ( copied system SID)  . my query here is any advantage , if we use the same SID as Production( in this eg: use ABC)/ Any issue if we use different SID . Just looking for the non-prd environment. Any suggestions from your side

 

[chrymt]

As mentioned by Boris, using DMO you cant change SID. If you have to change SID, then you have to do System Rename post DMO.

[rupesh_shivathare1]

Hi Boris,

Thanks for sharing wonderful news with the new technology offered by SUM SP17. I tried it on the customer system and it worked without any major issues.

I did the below changes apart from DMO Guide:

• Mounting DIR_GLOBAL on Target AAS


• Increased dialog runtime on AAS as enqueues were taking very very long times on AAS


• Enqueue TCP entries are not released on Enqueue host and sometimes need to restart Enqueue (TCP parameters on OS have to be fine-tuned though!)


• Latency calculated by SUM tool was lower than NIPING/TRACEROUTE commands

Overall it's a very interesting approach!

 

[r-yamagata]

Hi Boris,

Thanks for sharing very useful topic about SUM tool every time.

Could you let me ask about switching back to source system during Homogeneous DMO?

In Japan, customer tend to prepare new machine for target version in S/4HANA upgrade & conversion project. There are some reasons as below.

• They will plan OS/DB version upgrade on the same downtime


• They will plan cloud shift in this project on the same downtime


• They want to have switch back server for source system

Therefore, they can't utilize uptime of SUM as actual uptime.

All of SUM process is downtime for them.

 

Question:

• Can Source and Target system have different OS and DB version during Homogeneous DMO?


• Will Shadow repository create on target HANA DB ?


• After the SUM process, will source system remain original S/4HANA version?

Best Regards,

Ryohei

[Boris_Rubarth]

Hi Ryohei,

thanks for asking.

Maybe you are mixing up or combining aspects of homogeneous DMO with aspects of data center move.

The homogeneous DMO is like a standard DMO migration between two different database types:

• Shadow repository is created on target database, this is valid for all migration scenarios of SUM 2.0.


• SAP HANA DB version in source can be lower than the version in target.

"different OS": if this is related to OS of Application Server hosts, this is only relevant for a data center move (e.g. "DMO with system move"), for which Application Server hosts in source and in target landscape exist. For this case, the OS may be different.

"After SUM process, will source system remain original S/4HANA version?" You have to consider that the homogeneous DMO as such is a kind of plain DMO also in the sense that there is only one system, not two systems. After the homogeneous DMO, there is no source system any longer, so it will not remain. Only the source database is remaining, but like for plain DMO, it can't be used (like stated in the respectivive SAP Note for DMO).

Only for "DMO with system move", we have two systems and after the procedure, it is possible to reset the source landscape independent of the target system.

DMOVE2S4 is like plain DMO: no "independent reset" possible.

Best regards,
Boris

[r-yamagata]

Hi Boris

 

Thank you for your kind reply.

 

As you mentioned, I was asking the combination of homogeneous (HANA to HANA) DMO and DMO with system move. Thank you for clarifying my question.

Now, I realize that the homogeneous DMO is like a standard DMO (Non-HANA to HANA) and that "DMO with system move" can reset the source landscape independent of the target system.

 

I understood that the homogeneous DMO with system move is the solution which solve the customer's requirement to remain source system as original version independent of the target system.

 

Anyway, homogeneous DMO is great solution for SoH and S/4HANA customer trying to move cloud.

Thank you for this great solution.

 

Best Regards,

Ryohei

 

 

 

[former_member876928]

Hi Boris,

Thanks for the useful blog.

There are some clarifications on the homogeneous DMO.

Source: S/4 HANA 1909

OS: RHEL

1) Can the AAS on target host be of different OS. The source OS is RHEL and the AAS host can be SLES?

2) Is there any option like Homogeneous DMO with system move where the source environment can be retained after the S/4 HANA upgrade?

Regards

Rakesh

[Boris_Rubarth]

Hi Rakesh,

1. the requirements for the OS of the AAS are related to the database, not to SUM, e.g. for MS SQL, AAS can't run on Linux. For SAP HANA, you will have to check PAM.


2. Not sure if I got the question: DMOVE2S4 does not have an option to retain the source environment, but this is independent on whether homogeneous DMO is used or not.

Regards,
Boris

 

[former_member876928]

Hi Boris,

Thanks for the prompt response.

It's clear about the point 1.

The scenario about point 2 is as below:

Source: S/4 HANA 1909

OS: RHEL

Target: S/4 HANA 2022

OS: SLES

Cloud: Azure.

After the homogeneous DMO, there is no source system any longer, so it will not remain.

So for retaining source system version, the only option is DMO with system move but it works only for non-hana DB to HANA DB correct but in this case the database is already HANA

 

[Boris_Rubarth]

Hi Rakesh,

> DMO with system move but it works only for non-hana DB to HANA DB

This is not correct, see illustration in section 2.7 above.

Regards, Boris

[r-yamagata]

Hi Rakesh and Boris

Please let me add my comment.

Boris told me about reset the source landscape independent of the target system in my query.

>Only for "DMO with system move", we have two systems and after the procedure, it is possible to reset the source landscape independent of the target system.

Prior SUM 2.0 SPS17, "DMO with system move" works only for non-hana DB to HANA DB.

But after SUM 2.0 SPS17, "DMO with system move" also works for HANA DB to HANA DB.

Is it correct?

BR,

Ryohei

[Boris_Rubarth]

Hi Ryohei,

after [i.e. with] SUM 2.0 SPS17, "DMO with system move" also works for HANA DB to HANA DB.

correct (with potential restrictions listed in the respective SAP Note on DMO).

BR, Boris

[former_member876928]

Hi Boris,

Thanks for the prompt response once again.

I got your point now.

So my understanding is that if you want to retain source release version then use DMO with system move if not required then use DMOVE2S4.

Regards

Rakesh

[klaushuebner]

Hello Boris,

a great blog, thank you.
I have a very different question about the SUM. It was possible in SUM 1.0 to add a configuration file to the SUM. Is there something similar for the SUM 2.0 ?

Regards Klaus

[florian_thomas]

Hello Klaus,

the usage of a configuration file is still possible in SUM 2.0. Find more details on how to use it in the SUM Guide -> Running the Software Update Manager Again Using a Configuration File.

Best regards, Florian

[gianlucadm]

Hi Boris,

very good article, thank you.

 

I've some question on the DOMEV2S4 approach. It seems to be pretty similar to a standard DMO approach which can be done with previous SUM releases. It's not clear to me which are the differences between SUM 2.0 SP17 and the previous release. What if I follow the DOMEV2S4 approach using the previous SUM release, let's say SUM 2.0 SP14.

 

Thanks

Regards

Gianluca

[Boris_Rubarth]

Hi Gianluca,

thanks for asking. We have done some internal adaptations in SUM processing, thus we only support the scenario with SUM 2.0 SP 17 (and higher). Anyhow there is no reason to use an outdated SUM SP version.

Regards,
Boris

[gianlucadm]

Thank you for your quick response. I read about these adjustments in the SUM guide, I was just curious what they were.

 

Thanks

Regards

Gianluca

[hasanbacioglu]

Hi Boris,

Normally, first standart conversion is made to get FI customizing request then comes DOC with FI customizing request put into customer buffer.

Can we use, in sandbox runs and production run, doDMO in DMOVE2S4 setup for obtaining FI Customizing Request (instead of Standart Conversion to avoid export import) for DOC in DMOVE2S4 setup?

[chrymt]

Hi Hasan,

Before running any downtime optimized procedure, a standard run is always recommended for impact analysis. Boris may add additional points.

[Boris_Rubarth]

Hi Hasan,

thanks for asking. My answer is hidden in the following long text 🙂 and it is independent on whether DMOVE2S4 is used or not.

As you state, for the downtime-optimized Conversion (doC) run, the FIN customizing request is required. So prior to the doC run, it is necessary to have a "standard" conversion run prior to create that FIN customizing request. For the creation of that FIN customizing, we need to have the system in the "intermediate" state (after SUM run) in which the respective IMG activites can be executed (and recorded in the request). For this purpose, it is not relevant how this "intermediate" state was achieved: whether SUM executes its conversion activities as standard conversion or with downtime-optimized DMO (doDMO: migrating large application tables in uptime). Overall, my answer is simply "Yes, you can".

Let me add the question why you want to do this: doDMO may be higher effort than a standard conversion and may have overall a longer uptime phase, so the overall conversion duration (until you reach that "intermediate" state) may be longer. Maybe it is because you want to get familiar with doDMO, as the doC run will include uptime migration as well?

Regards,
Boris

[tomas_black]

Hello Hasan,

 

an additional comment on top of Boris' one: the Standard Conversion does not use Export/Import as you mentioned on your comment. It performs the data migration entirely on Technical Downtime using the DMO technology.

Best regards,

 

Tomas

[hasanbacioglu]

Thanks your for kind reply,

Whenever I hear, "Yes, you can", I am the happiest man on earth.

First, to get familiar with a similar uptime migration phase of DOC.

A lighter version is always welcome to start with.)

Our export and import duration is quite high, around 40 hours. There is evidently something wrong with that.

We just want to see if only doDMO could somehow last shorter since there will be no end-user activity with little or no replay afterwards.

As for, I don't know if we can call our approach DMOVE2S4 or not.

Due to latency issues, (from Turkey to Germany), we have assembled a hana machine on prem.

We have set up an AAS connected to MS SQL server and HANA DB, and then first we started doDMO run (target being the same HANA DB with 2 tenants.

Then a few days later we started DOC run with target being  the same HANA DB (different tenant).

As early starter doDMO, doDMO is always ahead with SI checks and other steps, followed by DOC running.

It is kind of having semi-parellel runs.

So we can proceed and finalize doDMO to get a more recent copy of production (without a Standart Conversion.), once our first DOC run is finished (which we have started to get familiar with a stale FI customizing)

We can directly make a second DOC run with a fresh FI customizing request.

Does it sound awkward?

We will see within a couple of months.

Thanks for your kind reply here, I have not noticed it.

Just ignore my same question in another thread.

Best heartfelt regards,

[hasanbacioglu]

Hi Boris,

I have yet another question.

In doDMO selection for uptime processing is through a flat file.lst.

Since we simply wanted to walkthrough DOC very quickly in the first run, we have implemented SUM Toolbox as TCI not in production but in QA system.

But the files left for Downtime processing still contain many large tables like GLPCA, MLCR etc.

Is it possible to add a list of files for uptime processing in DOC just like it is possible in doDMO?

How to move XPRA, XCLA to uptime processing in DOC?

Best regards,

[hasanbacioglu]

Oh la la land,

We are rushing through conversion since clock is ticking quite fast.

In ADM329 it is depicted that there shoud be breakpoints at  PARRUN_SMIG_SFIN and PROCESS_REPLICATE_RRC_START. But it is not explained what to do in these breakpoints.

In any case, our implementation partner did not even put breakpoint at PARRUN_SMIG_SFIN at all and conversion is started in SUM.

I can see in SM66 that there are database procedures calling BSEG  FAGLFELXA etc. and follow the jobs in SM37. By means of job name, I understand that we are at R21.

But since we have not logged in TMP and started any FINS_MIG_STATUS run manually, there is nothing there.

In SUM, we can see that we have data inconsistency error . But we do not know how to accept or correct it. (Normally, in FIN_MIG_STATUS, it was made visually.)

doconv_sum20_s4hana -

It is written:

Issues can occur due to the following reasons:
•
Missing Customizing:
•
The actual migration process cannot start without a Customizing and is highly dependent on data constellation.
•
The Customizing transport does not fit anymore due to recent changes in the source system's configuration. The safest approach in this case is to reset the SUM and provide an appropriate Customizing.
•
Inconsistent data:
•
There might be situations when manual intervention in data or wrong archiving left the data in the source system in an inconsistent state from the data model's perspective.
•
Depending on the situation, the Finance expert could accept the errors and, in the next cycle, correct the data in the source system. Also in this case, a safe approach is to reset the SUM and perform data correction in the source system, if time allows.

How can we accept errors in DOC sandbox run, and how can we correct them in production run without resetting SUM?

It might be catastrophe for production run to reset the SUM.

[Boris_Rubarth]

Hello Hasan,

please read the ADM329 material carefully!

> In ADM329 it is depicted that there shoud be breakpoints

No, the training uses breakpoints, but they are marked as training specific.

> But since we have not logged in TMP and started any FINS_MIG_STATUS run manually, there is nothing there.

Sorry to say that I don't understand that statement: errors will have to be analyzed in there, using the correct client.

Regards, Boris

[hasanbacioglu]

Hi Boris,

Finally, we have made it through and the first DOC run is finished successfully with many problem solved meanwhile.

It seems to be the only solution meeting requirements of our deadline.

However, our team is afraid of load verification on productive system and reset procedure (we hade failed to reset  in our run with DMO with system move, and we had to restore the system.

In ADM329, it is discussed briefly.

I have made research and  it is written in doconv_s20_s4hana

"Virtualization and Isolation of Clone due to Delta Loads Verfication
The concept of Delta Load Verification aims to simulate the downtime of the approach on production-like hardware. It creates a clone of the production system at the time of the downtime dialog. This only works if the clone is created using virtualization, so that the clone is identical from perspective of SUM (e.g. same host names). In addition, the clone must be completely isolated from the network of the production system."

I do not really get what is meant by virtualization and clone here.

After all, we have to make load verification run on productive system and reset it, right?

We are afraid of so many triggers set on all tables on productive DB.

What to pay attention in load verification?

What might go wrong in load verification and how we can overcome possible problems?

Thanks in advance for your kind guidance.

[hasanbacioglu]

Hi again,

One more critical question.

Although, we completed DOC run waiting at follow up activities screen,

There are many triggers still left in source DB!!!

Is it normal? Or maybe, we did not noticed it as a failure in tasklist?

I just wanted to know if source is really intact for fallback scenario,

Is there a documented manual clean up activity for trigger removal from source dB as a follow-up activity?

I have only included a couple of triggers left on screenshot, but there are many of them.

Regards,

 

[Rohit-Sharma]

Hi Boris,

Thanks for sharing great article .I am getting one repeated question from my customers planning for S/4HANA upgrade and Cloud migration.

Regarding section 1.2: Homogeneous option for DMO-

"Transition of an existing SAP S/4HANA (on-prem) system to SAP S/4HANA Cloud, private edition.

along with upgrading to higher SAP S/4HANA release"- Is it valid for RISE with SAP customers ?

My customer is planning for S/4HANA 1909 on-premise to Rise Migration with target S/4HANA 2022 release - Can we leverage this option .Kindly confirm

Thanks,

Rohit Sharma

[Boris_Rubarth]

Hi Rohit,

yes, homogeneous DMO can be used for such RISE projects.

Regards, Boris

[Rohit-Sharma]

Thanks Boris for the confirmation ! It really helps.

Regards,

Rohit Sharma

[hasanbacioglu]

Hi Boris Rubart,

We proceed with DMO of SUM with system move.

We achieved to reduce export from 20 hours or so to 3 hours with potential reduction to 2 hours (MSSQL) or less, but have some problems with import on HANA (Rise private - around 8-9 hours).

I have seen that R3LOAD has -c option to force commit after every commit count rows (only for import).

Is it possible to set this count value through environment variables SAPup_add.par or somehere else?

In which way it would affect import to HANA DB?

You have guided us up to this phase of the project and your kind comments will be appreciated as always.

Regards,

[Boris_Rubarth]

Hi Hasan,

thanks for asking and for the feedback. Unfortunately I can only provide guidance for some cases.

Specifically for that R3load parameter, it is not considered to provide it to SAPup.

In general, from what you report, it would be worth analyzing the logs to detect where a potential bottleneck could be.

I assume that the number of R3load processes was adapted to the performance of the host ... sure you know that it is not uncommon to have more than 200 processes for downtime migration.

Regards,
Boris

[rylands]

Hi Boris.

Great Blog!

In case of an upgrade of S/4 HANA On Premise from 1909 to 2023 combined with a relocation to a different datacenter we see now two ways of achieving this.

Either by the new Homogeneous DMO or simply by utilizing Systemreplication during a standard SUM run. The takeover in the new datacenter can take place before or after SUM run depending of in which environment the upgrade should take place. Of course we would need to install and establish the PAS in the new datacenter separately.

Would the Homogeneous DMO bring any advantages to such a process compared to a systemreplication approach?

 

BR

Sveinung Ryland

[Boris_Rubarth]

Hi Sveinung,

thank you for the feedback.

Please consider SAP Note 3345671 - SAP HANA: Additional information - Software Update Manager, it lists your approach of using HSR during SUM runtime as not supported.

BR,
Boris

[Rohit-Sharma]

Hi Boris,

Another great blog , Have referred multiple time , It is really helpful.

One of my customer is approx. 22 TB on oracle and they are looking to move on Suite on HANA on Azure . For this scenario it seems both the options ( Homogeneous Migration & DMOVE2S4)  are not available as Target is not S/4HANA and Downtime Optimization DMO is also not available for SUM using System Move

Considering these scenarios - Please suggest if any downtime optimization approach like doDMO , nZDT are available as PILOT . 

[MasayoNakajima]

Hi boris.rubarth,

Thanks Boris for this wonderful blog!

Can you please provide some thought on using the SID during the SUM DMO migration (DMO with system move option).

Which instances require the source and target systems to have the same SID?

I understand that the ASCS and PAS instances must be the same on the source and target systems. Does the SID of the HANA system also need to be the same on the source and target systems?

Best regards,