# SAP ECC Unicode Conversion Downtime Estimator for the EHP8 / NetWeaver 7.50 Path

> Source: https://netray.co/tools/sap-ecc-unicode-conversion-downtime-estimator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate the technical downtime of a non-Unicode SAP ECC 6.0 system's Unicode conversion from database size, R3load throughput, parallel processes and the largest table.

## Category

sap

## Erp

SAP ECC 6.0

## Audience

- SAP Basis administrator
- SAP technical architect
- Upgrade project manager

## Tool

**Kind:** calculator

**Inputs:**

#### Database size (used, not allocated)

**Key:** db_size

**Type:** number

**Default:** 2000

**Min:** 10

**Step:** 50

**Unit:** GB

**Help:** Used data size from DB02 or the database's own tools. Index space is rebuilt, not exported, so use table data if you know it.

#### Largest single table

**Key:** largest_table

**Type:** number

**Default:** 300

**Min:** 0

**Step:** 10

**Unit:** GB

**Help:** Typical candidates: CDCLS, EDI40, BSEG cluster RFBLG, COEP, ACCTIT, SOFFCONT1, BALDAT. Take it from DB02 top tables.

#### Throughput per R3load process

**Key:** thr

**Type:** number

**Default:** 15

**Min:** 0.5

**Step:** 0.5

**Unit:** GB/hour

**Help:** Measure this in a test conversion on a production copy. It is the single most important input.

#### Parallel R3load processes

**Key:** procs

**Type:** slider

**Default:** 24

**Min:** 4

**Max:** 64

**Step:** 1

**Help:** Limited by CPU cores, I/O and memory on source and target.

#### Table splitting packages for the largest table

**Key:** split_parts

**Type:** number

**Default:** 8

**Min:** 1

**Step:** 1

**Help:** 1 means no splitting. With splitting, the largest table runs as several R3load packages in parallel.

#### Import speed relative to export

**Key:** import_factor

**Type:** number

**Default:** 1

**Min:** 0.2

**Max:** 3

**Step:** 0.1

**Help:** 1.0 means import runs as fast as export. Below 1 means import is slower (index creation, logging).

#### Export and import mode

**Key:** mode

**Type:** select

**Default:** 1

**Options:**

##### Parallel export/import (Migration Monitor socket or file transfer)

**Value:** 1

##### Sequential (export finishes, then import)

**Value:** 0

#### Post-conversion steps inside downtime

**Key:** post_hours

**Type:** number

**Default:** 6

**Min:** 0

**Step:** 0.5

**Unit:** hours

**Help:** Index rebuild not covered by import, statistics, SUMG steps that must run before users return, technical checks.

#### Test-run calibration factor

**Key:** calib

**Type:** number

**Default:** 1

**Min:** 0.5

**Max:** 3

**Step:** 0.05

**Help:** Actual test runtime divided by this calculator's estimate for the test run. Apply it to production.

**Outputs:**

#### Bulk export time

**Key:** export_h

**Expr:** db_size / (thr * procs) * calib

**Format:** hours

**Description:** Database size divided by total export throughput (per-process throughput times processes), calibrated.

#### Bulk import time

**Key:** import_h

**Expr:** export_h / import_factor

**Format:** hours

#### Bulk runtime (export + import)

**Key:** bulk_h

**Expr:** if(eq(mode, 1), max(export_h, import_h) * 1.2, export_h + import_h)

**Format:** hours

**Description:** Parallel mode: the slower of export and import plus a 20% overlap allowance (rule of thumb). Sequential mode: export plus import.

#### Largest table export time

**Key:** largest_exp

**Expr:** largest_table / (thr * min(split_parts, procs)) * calib

**Format:** hours

#### Largest table path (export + import)

**Key:** largest_h

**Expr:** if(eq(mode, 1), max(largest_exp, largest_exp / import_factor) * 1.2, largest_exp + largest_exp / import_factor)

**Format:** hours

**Description:** One table cannot use more processes than it has packages. If this path is longer than the bulk runtime, splitting the table helps more than adding processes.

#### Technical conversion runtime

**Key:** technical_h

**Expr:** max(bulk_h, largest_h)

**Format:** hours

#### Estimated downtime

**Key:** downtime_h

**Expr:** technical_h + post_hours

**Format:** hours

**Primary:** true

**Description:** Technical runtime plus post-conversion steps that must finish before users return. Add your own buffer for start-up, checks and business sign-off.

#### Largest table path vs technical runtime

**Key:** largest_share

**Expr:** largest_h / technical_h * 100

**Format:** percent

**Description:** 100% means the largest table is the critical path.

**Chart:**

#### Downtime vs parallel R3load processes

**Type:** line

**X:** procs

**From:** 4

**To:** 64

**Steps:** 31

**Series:**

- downtime_h
- bulk_h
- largest_h

**Disclaimer:** Rule-of-thumb planning model, not an SAP formula. Real throughput depends on database, storage, network, table structure and cluster/pool table handling. Only a test conversion on a production-size copy gives numbers you can commit to.

## Content

**Intro:** This estimator gives a first downtime figure for converting a non-Unicode SAP ECC 6.0 system to Unicode, which must happen before the system can move to EHP8 on SAP NetWeaver 7.50. It models R3load bulk export and import, the critical path of the largest table and the post-conversion work inside the outage.

**Sections:**

#### Why Unicode comes first on the EHP8 path

**Body:** SAP NetWeaver 7.50, the technical stack under ECC 6.0 EHP8, runs only on Unicode systems; NetWeaver 7.40 was the last release that supported non-Unicode. A non-Unicode ECC system on EHP4 to EHP7 therefore needs a Unicode conversion before or as part of the move. The classic combined upgrade and Unicode conversion (CU&UC) belonged to older upgrades from releases such as 4.6C into ERP 6.0, so do not plan on it for 7.50. The usual sequence is: Unicode conversion of the current release, then the SUM upgrade to EHP8. If you are also moving to SAP HANA, the Database Migration Option (DMO) of SUM can include a Unicode conversion for some source systems; check the current DMO guide for the supported combinations before you build a plan on it.

**Bullets:**

- Preparation: SPUMG (scanner, vocabulary, language assignment) on ECC 6.0; SPUM4 is the variant for older releases
- Downtime: R3load export of the non-Unicode database and import into a Unicode database, driven by SWPM and the Migration Monitor
- Post-conversion: SUMG to repair data the scanner flagged, plus technical follow-up

#### The method behind the numbers

**Body:** Bulk runtime is database size divided by total throughput: per-process GB/hour times the number of parallel R3load processes. Import time is export time divided by the import speed factor. In parallel export/import mode the two overlap, so the model takes the slower side and adds 20% for start-up and tail effects; sequential mode simply adds them. The largest table is a separate path: it can only use as many processes as it has split packages, so its time is table size divided by throughput times the number of packages. Downtime is the longer of the two paths plus your post-conversion hours. All of this is a rule of thumb used for early planning. Replace the throughput with the figure from your own test run, then use the calibration factor to correct for anything the model misses.

#### Worked example

**Body:** A 2,000 GB ECC database, 15 GB/hour per process and 24 processes gives 360 GB/hour, so export takes about 5.6 hours. With import at the same speed and parallel mode, bulk runtime is about 6.7 hours. The largest table, 300 GB split into 8 packages, needs 300 / (15 x 8) = 2.5 hours to export, or 3 hours on its path with overlap, so it is not critical. Add 6 post-conversion hours and the estimate is about 12.7 hours. Without splitting, the same table would need 20 hours to export alone, and the downtime would jump to about 30 hours: this is why table splitting is planned for the top tables in nearly every large conversion.

**Bullets:**

- Use the chart to see where more processes stop helping
- If the largest-table share reads 100%, split that table further
- Recalculate after every test run with the calibration factor

#### Common mistakes

**Body:** Using allocated database size instead of used data overstates runtime. Taking throughput from someone else's project understates it more often than not. Forgetting cluster tables such as RFBLG and CDCLS, which R3load has to unpack and repack during a Unicode conversion and which run slower than transparent tables of the same size. Leaving SUMG work for after go-live without checking which corrections must happen before users log on. Planning the conversion and the EHP8 upgrade in the same weekend without a full rehearsal of both. Ignoring growth: a Unicode database can be larger than the source depending on the database encoding, so size the target storage from the test run.

**Cta:** If you want your Basis team to query conversion logs, R3load timings and DB02 history in plain English on your own servers, we can set that up alongside your ECC system.

**Faq:**

#### Can I upgrade a non-Unicode SAP ECC 6.0 system directly to EHP8?

**Answer:** No. EHP8 runs on SAP NetWeaver 7.50, which supports only Unicode systems. Convert the system to Unicode first, on its current release, then run the SUM upgrade to EHP8. If you are also moving to SAP HANA, check whether DMO of SUM supports a Unicode conversion for your source system and code page.

#### What are the phases of an SAP Unicode conversion?

**Answer:** Preparation in the running system with SPUMG (scans, vocabulary, language assignment for ambiguous data), the downtime export of the non-Unicode database with R3load and import into a new Unicode database through SWPM, and post-conversion work with SUMG plus technical checks. Test runs on production copies come before the production conversion.

#### How do I reduce Unicode conversion downtime?

**Answer:** Measure a test run, split the largest tables into packages, run export and import in parallel, add R3load processes until CPU or I/O saturates, archive or delete data you do not need beforehand, and order packages so the largest start first. The chart in this tool shows where adding processes stops paying off.

#### Is this an official SAP downtime formula?

**Answer:** No. It is a planning rule of thumb based on throughput and parallelism. SAP's guidance is to measure with test conversions on production-size copies. Use this estimate to set expectations and choose split candidates, then replace the inputs with measured values from your own runs.

## Search terms

sap unicode conversion downtime, upgrade sap ecc 6.0 ehp4 to ehp8, sap ecc 6.0 upgrade, sap upgrade ecc 6.0 to ehp8, sap erp upgrade process, r3load export import time, sap unicode conversion table splitting, spumg sumg unicode

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json