01
Collect
Receives spreadsheets, legacy-system exports, database extracts, shared-drive folders, and sample records into one controlled source pack.
Your team Providing source access and naming the system owner.
Workflow stack
Move legacy records cleanly.
Scellus cleans, maps, checks, loads, and verifies legacy records before and after they move into the new system. Your team keeps the business decisions; we run the operating queue that makes the migration trustworthy.
- Included
- Duplicate detection built in
- Included
- Mapping documentation
- Included
- Post-load verification
Built for teams moving from spreadsheets or legacy software into a new CRM, ERP, HR, accounting, cloud, or custom operating system.
Where migration breaks today
The load finished. The records still did not agree.
- 01
The spreadsheet has three customer IDs for the same company. One came from the old CRM, one from finance, one from a branch-level export. The new system accepts all three and nobody notices until reporting splits the account.
- 02
The legacy export looks complete because every row loaded. Then the first renewal cycle starts and the missing tax IDs, stale addresses, inactive staff records, and inconsistent labels turn into support tickets.
- 03
The migration plan says cutover weekend. The operating reality says the team still needs the old system open on Monday because nobody trusts whether the new records match the source.
- 04
The clean-up work sits with the busiest people. They know which field is wrong, but not where every duplicate lives. The project waits for tribal knowledge instead of moving through a controlled queue.
Operating truth
A migration is not clean because the import succeeded.
It is clean when the source, the transformation, the reviewer decision, the load batch, and the destination record can still be traced after the new system goes live.
The stack
Six blocks. One controlled move.
Data cleanup and migration needs the full public block sequence. The work starts with source inventory, passes through mapping and validation, pauses for business judgement where the source is unclear, then delivers a clean destination record and audit trail.
- 01 Collect
- 02 Read
- 03 Verify
- 04 Chase
- 05 Review
- 06 Deliver
02
Read
Extracts fields, normalises labels, reads table structures, and builds the working map between source fields and destination fields.
Your team Confirming the business meaning of ambiguous fields.
03
Verify
Checks duplicates, missing required fields, invalid formats, stale records, referential gaps, and post-load counts before sign-off.
Your team Approving the validation rules and tolerance thresholds.
04
Chase
Routes unclear source records to the person who can resolve them, with the record, source file, and proposed fix attached.
Your team Answering exceptions that require business judgement.
05
Review
Holds risky batches, unusual mappings, and parallel-run differences for named review before records are committed downstream.
Your team Signing off batch release and cutover decisions.
06
Deliver
Loads the clean dataset into the destination, preserves the audit trail, and hands over validation, batch, and exception reports.
Your team Operating the destination system after acceptance.
What you receive
Not an import file. An operating record.
The output is not just clean data. It is the evidence that shows which records moved, which records were held, and why.
-
A cleaned source dataset with duplicates, blank required fields, invalid formats, stale values, and inconsistent labels marked or corrected according to the agreed rules.
-
Mapping documentation showing each source field, the destination field, transformation logic, owner, exception state, and sign-off status.
-
Validation reports before load, after load, and after user acceptance checks, so the team can see what passed and what still needs a decision.
-
Batch load results with counts, rejected rows, corrected rows, skipped records, and the reason behind each hold.
-
A review queue for ambiguous records: duplicates that may be legitimate, inactive records that may need retention, and fields that need business context.
-
Parallel-run notes where required, comparing the old source and new destination through the bridge period before cutover.
-
An audit trail that links source record, transformation, reviewer decision, load batch, and destination record.
The transition
What changes when Scellus runs the migration workflow.
Duplicate and stale records
Today
Duplicates are found by whoever happens to recognise a name. Stale records move because the export did not know they were stale.
We handle
We group likely duplicates, mark inactive or outdated records, and route uncertain matches to a named reviewer before load.
Your team
Defines what counts as a live record and approves uncertain merges.
Field mapping and transformations
Today
Mappings sit in a spreadsheet, then drift as the destination system changes or a late source export arrives.
We handle
We maintain the mapping document as the operating record: source, destination, transformation, owner, exception rule, and sign-off.
Your team
Confirms the business meaning of fields that are not self-explanatory.
Cutover confidence
Today
The project celebrates when the import finishes. Errors surface only after teams start using the new system.
We handle
We validate before load, after load, and during the bridge period, with holds for records that should not move automatically.
Your team
Approves batch release and the final cutover point.
Division of labour
We run the queue. You keep judgement.
Scellus handles Your team owns
Inventory source files, exports, tables, and folders
Provide source access and name the data owner
Build the source-to-destination field map
Confirm field meaning, mandatory fields, and destination constraints
Clean formats, labels, duplicate groups, and required-field gaps
Decide ambiguous merges, inactive records, and retention edge cases
Prepare batch loads and validation reports
Approve the release sequence and downtime window where needed
Run parallel checks between source and destination
Confirm which operating reports must match before cutover
Maintain audit traceability from source to destination
Define who can access the audit pack after go-live
Operate the post-launch error tail
Own policy decisions that change the source-of-truth rule
Compliance and data
Sensitive records stay traceable while they move.
Personal, staff, customer, supplier, finance, and operating records stay under PDPA 2010 and the 2024 Amendment. The migration plan names source location, destination location, access owner, retention rule, and audit handoff before records move.
Data residency matters when source files contain employee, customer, financial, or regulated records. The Workflow Review confirms which datasets can move, where they can be processed, and which records require masking, holdback, or reviewer approval.
Audit traceability is part of the deliverable: source record, transformed record, reviewer decision, load batch, destination record, rejected-row reason, and final acceptance note.
Integrations
We meet the old system and the new one.
Source systems
- Spreadsheets and CSV exports from legacy teams
- Shared drives, cloud folders, and document archives
- Legacy CRMs, ERPs, HR, payroll, and accounting systems
- SQL databases, app exports, flat files, and custom tables
Destination systems
- CRM, ERP, HR, payroll, accounting, and custom operating systems
- Microsoft 365, Google Workspace, SharePoint, and cloud folders
- Data warehouses, reporting tables, and operational dashboards
- New line-of-business systems built around a clean master record
Control layer
- Mapping workbooks and validation reports
- Reviewer queues for ambiguous rows and risky batches
- Batch logs, rejection files, and post-load counts
- Audit archives for source, transformed, and destination records
Side-by-side rollout and sync
The bridge period is operated, not wished away.
Bridge
Where required, Scellus operates the source and destination in parallel long enough to compare counts, spot reporting differences, and fix mapping gaps before the old system is retired.
Cutover
Cutover happens by batch and approval state, not by hope. Held records stay visible, accepted records move with their audit trail, and rejected rows have an owner.
Error tail
After launch, Scellus works the remaining errors as an operating queue: missing fields, duplicate disputes, reporting gaps, permissions, and records the old system hid.
Common sources and destinations
Most migrations fail between systems, not inside one system.
Sources
- Spreadsheets
- Shared drives
- Legacy apps
- Databases
Destinations
- CRM
- ERP
- HR or payroll
- Accounting
Bridge controls
- Mapping doc
- Validation report
- Review queue
- Audit trail
Acceptance
- Batch counts
- Rejected rows
- Parallel checks
- Cutover sign-off
Operating cadence
Source inventory, clean batches, controlled cutover.
01
Week 1 to 2
Discovery and source inventory
We list source systems, owners, export formats, required destination fields, sensitive datasets, and the reports that must still reconcile after cutover.
Migration scope and source inventory agreed. 02
Build phase
Clean, map, and validate
Records are cleaned in batches, mapping is documented, exceptions are routed, and validation reports are produced before the destination receives a controlled load.
Clean load pack and exception queue ready. 03
Cutover and after
Load, parallel-run, and close
Accepted batches move into the new system. We compare source and destination, operate the post-launch error tail, and close with an audit pack.
Destination accepted with traceability.Indicative scope
Clean enough to load. Traceable enough to trust.
Build phase
Six to twelve weeks
Source inventory, mapping, cleaning rules, duplicate logic, validation reports, reviewer queue, batch-load process, parallel-run, cutover support, and audit pack.Operating retainer
Post-launch support
Exception handling, rejected-row cleanup, reporting differences, data quality fixes, access and audit support, and rule updates while the new system stabilises.Final scope, duration, and fee are confirmed at the Workflow Review against source count, destination complexity, data sensitivity, and cutover constraints.
What clients ask first
The questions that decide whether a migration is ready.
-
What if our source data is too messy?
- That is usually the reason to treat the migration as an operated workflow. We separate clean records from exception records, move what can be trusted, and hold the rest with an owner and a decision path.
-
How do you reduce data loss risk?
- We keep source files, transformed files, load batches, rejection reports, and destination counts connected in the audit trail. Records do not disappear into a single import file.
-
Can we avoid downtime?
- Some migrations can run in parallel with staged batches. Others need a cutover window. The Workflow Review identifies which pattern fits your system, data volume, and user behaviour.
-
Who decides ambiguous duplicates?
- Your team keeps the judgement call. Scellus prepares the duplicate group, source evidence, proposed rule, and reviewer queue so the decision is fast and documented.
-
What happens after launch?
- The first month usually reveals the error tail: records nobody trusted, old labels hidden in reports, and permissions that need tightening. We operate that queue instead of leaving it with your project team.
Find out what your migration would need before cutover.
Start with the records, systems, owners, and reports that have to survive the move. We will map the source, the destination, the risks, and the first workflow to operate.