Legacy CRM to Salesforce
From an on-premises or hosted CRM, usually with years of local conventions, free-text where a picklist should have been, and reports nobody can reproduce.
The hard part is rarely extraction. It is deciding what the fields were actually being used for, which only the users can tell you.
A model that matches how the work is done.
Org consolidation
Two or more Salesforce orgs into one after an acquisition, where both sides have a working data model and neither wants to be the one that changes.
The decisions are organisational before they are technical. We make that explicit early instead of letting it surface at cutover.
One org with a model both sides recognise.
Classic to Lightning
Moving the interface and, more importantly, the automation and customisation behind it that was written against the old one.
The interface switch is the visible part and the small part. Overlapping legacy automation is the work.
A move that does not re-break what worked.
Data and deduplication
Extraction, cleansing, matching and merge rules agreed with the business, with the survivorship decisions made by the people who own the records.
Merging accounts on rules the business has not approved is the quickest way to lose their trust permanently.
Duplicates resolved the way the owners wanted.
Attachments and history
Files, notes, activity history and audit trail, which is usually the largest volume and the part that gets deferred until it is a problem.
A migration that moved the records but not the correspondence is one users work around rather than adopt.
The context, not only the record.
Legacy decommission
A read-only period on the old system, a retention position agreed with whoever is responsible for it, and a decommission date that is a decision rather than a drift.
Systems kept alive because nobody decided to switch them off are a cost and a liability at once.
An ending that was planned.