The risk in a migration is not the technology — it is accumulated customization.

SAP migrations usually stall not on standard functionality but on customizations added over years. Sanal Çekirdek starts by building that inventory: which development is still in use, and which is not.

We work independently and claim no vendor partnership or competency level. Our role is to make scope, data and risk visible.

Build your customization inventory Back to Enterprise Applications

Customization and usage inventory

Every customization is a migration cost. Usage data shows which developments actually run; the unused ones do not travel. This is the step that shrinks scope most.

Usage data covers at least the past year
Unused developments are archived rather than migrated
Customizations with a standard equivalent are flagged
Developments with no owner are listed separately

Data quality and conversion

Master data quality is the most underestimated line in a migration. Duplicate supplier and material records carried into a new system continue growing there; cleanup belongs before the move.

Master data cleanup completes before migration
Conversion rules are proven with trial loads
The scope of historical data is decided explicitly
A reconciliation report follows every load

Cutover window and rollback

The most critical part of the plan is the window in which the business stops. It is reconciled with the business calendar, its duration is measured through rehearsal loads, and a threshold is set for the rollback decision.

Window duration is measured with rehearsal loads
Rollback threshold and decision owner are written down
A manual-processing list is prepared for the cutover
The first period close after go-live is supported separately

Stability after go-live

A migration does not end on go-live day. The first period close, interface behavior under load and support demand are planned separately, with extra capacity reserved for that stretch.

Extra support is planned for the first period close
Separate monitoring is set up for interface errors
User questions are classified and fed back into training
Open items are tracked to a closing date

How we work

Build the customization and usage inventory
Complete master data cleanup before migration
Measure the window through rehearsal loads
Set the rollback threshold and its owner
Plan the post-go-live period separately

How success is measured

Every migrated customization is justified by the inventory
The rehearsal load fitted inside the target window
The first close after migration completed on time
Every open item has an owner

Frequently asked questions

Are you an SAP partner?

No, and we claim no partnership or competency level. Our role is to make scope, data and risk visible; your product and licensing relationship runs through your own channels.

What determines the migration timeline?

Duration follows customization count and data volume; committing to a date before the inventory exists would be misleading. The first piece of work exists to make scope measurable.

Will our own team be involved?

They should be. Process knowledge lives in your organization; advisory combines it with method. The same team also operates the system after go-live.

Before discussing the migration itself, let's build your customization inventory — scope usually shrinks right there.

Build your customization inventory