Move your data once. Trust it from day one.
On go-live morning, your new system is only as good as the data inside it. We plan, clean, load and reconcile your master data and open balances with SAP's own migration tools. Then we rehearse until every total matches the system you're leaving.
Your data from today, not your history.
A new SAP system starts on a clean date. You bring over what you need to keep working the next morning: the records you use, what's still open, and the balances that carry forward. Years of closed transactions stay where they are, but you can still look them up.
Who and what you deal with
- Customers and suppliers, with bank and tax details
- Products, bills of material and routings
- Fixed assets
- Prices, contracts and conditions
Work still in progress
- Unpaid customer and supplier invoices
- Open sales and purchase orders
- Open projects and service orders
- Contracts still running
What carries forward
- General ledger balances
- Stock quantities and values
- Asset values and depreciation to date
- Bank balances for reconciliation
Kept, not migrated
- Closed transactions from past years
- Duplicate and inactive records
- Workarounds the new process removes
We keep history readable, in the old system in read-only mode or in an archive or reporting store.
Load in the right sequence, or nothing reconciles.
An open invoice can't load before its customer exists, and a stock balance can't load before its product. SAP's migration objects depend on each other, so we plan the loads as a sequence. The general ledger goes last, because it has to agree with everything loaded before it.
- 1 · SYSTEM SETTINGSConfigurationCompany codesChart of accountsPlants and storageTax codesSet up, not migrated
- 2 · MASTER DATABanksCustomers, suppliersProductsBOMs, routingsFixed assets, with values to date
- 3 · OPEN ITEMS AND STOCKOpen receivables and payablesOpen sales and purchase ordersStock balances
- 4 · CLOSING BALANCESG/L balancesLoaded lastMust equal the legacy trial balanceFinal sign-off
The migration cockpit is built in, and it checks every record.
SAP Cloud ERP includes the migration cockpit, the Migrate Your Data app, at no extra cost. It loads data through the same checks as the business apps, so a record that wouldn't save on screen won't load either. There are three ways to feed it, and we pick per object.
| Method | How it works | Best for |
|---|---|---|
| Templates | We fill SAP's Excel (XML) or CSV templates from your extracts and upload them. Each file can be up to 100 MB. | Most mid-sized projects and any non-SAP source |
| Staging tables | Data is loaded into a separate SAP HANA Cloud database with an ETL tool, then the cockpit takes it from there. | High volumes and loads you'll repeat several times |
| Direct transfer | The cockpit reads selected objects straight from an SAP ECC system by company code and converts them to the new data model. | Moving from ECC. Objects it doesn't cover still use templates. |
Remote staging uses SAP HANA Cloud, which is free up to a size limit and charged beyond it. We tell you up front if your volumes need it.
Three practice loads before the one that counts.
We never do a migration for the first time on go-live weekend. Each practice load, called a mock load, runs the full process on a test system with your real data. Errors fall with every round, and by the final rehearsal we know exactly how long cutover takes.
- PrepareOwners clean the source
- Mock load 1Does it load?~12%
- Mock load 2Do the totals match?~3%
- Mock load 3Timed, full volume<0.5%
- Go-live loadCutover weekend0
Illustrative values. Your error rates depend on the source system and how much cleaning happens up front.
Fix the data where it lives, before it moves.
Most migration problems are data problems: the same customer entered three times, suppliers without bank details, products without weights. We profile your source data early and give each problem to the person in your business who owns it.
In Sri Lanka this now matters more than ever. With RAMIS e-invoicing, invoices go to the Inland Revenue Department in real time, so a missing or wrong customer TIN is a rejected invoice on day one, not a correction at month-end.
Every total checked, by the people who own it.
Loading data is half the job. The other half is proving it arrived complete and correct. After each load we compare the new system with the old one, and the business owner of each area signs it off.
Record counts
Customers, suppliers, products and assets: what we extracted, what we excluded on purpose, and what loaded.
Receivables and payables
Open items by customer and supplier match the legacy ageing reports, invoice by invoice.
Stock
Quantities by product, plant and storage location, and the total stock value.
Fixed assets
Acquisition values, depreciation to date and net book value, asset by asset.
General ledger
The opening trial balance in SAP equals the closing trial balance in the legacy system, account by account.
Go-live decision
All sign-offs collected, open errors at zero, and the cutover timing proven in the dress rehearsal.
See the tools from SAP.
Videos from SAP’s official YouTube channels on the migration cockpit and how it fits into a Cloud ERP project.
Published by SAP on its official SAP and SAP Community YouTube channels. Older videos use the earlier product name, SAP S/4HANA Cloud Public Edition.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Straight answers.
Do we lose our history?
No. History isn't loaded into the new system, but you can still see it. The usual options are to keep the old system available in read-only mode for a period, or to move history into an archive or a reporting store. We agree the option and how long you keep it, with your auditors' requirements in mind.
We aren't on SAP today. Can you still migrate us?
Yes. Most of our sources are non-SAP systems, such as IFS, Microsoft Dynamics, Oracle, Sage, Tally or custom-built software. We extract the data, map it to SAP's templates and load it with the migration cockpit. Only moves from SAP ECC can also use the direct transfer option.
Who cleans the data, you or us?
Both. We profile the data, find the problems and build the rules and mappings. Your people decide what's correct, because they know which of three customer records is the real one. Fixing data at the source is always cheaper than fixing it after go-live.
How long is the business frozen at cutover?
Usually a weekend, sometimes a little longer for large volumes. The final mock load is timed, so the cutover plan is based on a measured run, not an estimate. We agree beforehand which transactions stop, and when.
Can we load data again later, for example after an acquisition?
Yes. The migration cockpit stays available after go-live, so a new company or a new business can be loaded the same way.
How is personal data handled?
Migration files contain personal data such as employee and customer contacts. We agree secure storage and transfer, limit access to named people, and delete working files when the project closes. The cockpit also deletes its migration data after a retention period you choose.
Know your data before you plan the project.
A migration assessment looks at your source systems and data quality early, so the migration is planned properly, not discovered late.
- Source systems and extraction approach
- Data quality profile of key objects
- Objects in scope and load sequence
- Method per object: template, staging or direct
- Mock load and cutover plan
SAP, SAP S/4HANA and SAP Cloud ERP are trademarks of SAP SE. Screens and charts shown are illustrations.
At Mawkish, the Isldale Standard is how we keep SAP Data Migration work checked, owned and answered for, whoever does the build.