Managed audits and migration for data-heavy systems
Rig maps every system, field, and flow in your data estate, with evidence attached to each call. Audit plan in 2 weeks, followed by a dry run. From there we run the migration or your team does it.
Audit plan in 2 weeks
Every drop call carries evidence
The map stays after we leave
What changes with Rig
- A consultant reads the source schema and hand-writes a mapping document
- Usage is guessed at, so everything gets migrated just in case
- The knowledge that explains the data sits with people who are leaving
- The first real test of the plan is cutover weekend
- You pay for the map, then pay again to rebuild it when it drifts
- The map is built from schema and observed usage together
- Every drop candidate carries evidence: who read it, how often, and whether that was a person or a pipeline
- Definitions and practice get written down in the context layer as you go, and keep updating
- The whole migration is dry run against a target instance before anything moves
- The platform stays behind, so the map is still current after we leave
Rig maps how your systems are actually used
What you are really migrating is ten years of workarounds: custom fields carrying meanings nobody documented, an integration quietly writing the number finance actually reports on, an object that has been dead since 2019. Rig treats all of it as evidence.
Rig reads the schema and the applied practice together. How records are genuinely structured, which fields are written to and by what, which pipelines and reports depend on them, and which parts of the estate nobody has touched in a year. That map is what the plan gets built on.
What an audit covers
- Object by object: dead fields, empty custom objects, automation nobody can explain, and the data that should be there and is not.
- Process mapping with the people who actually use the systems, mapped back to the schema.
- Blast radius: what a field or a process really touches, before you change it.
- Gaps between systems that a schema scan will not show.
- Seat and licence usage: who is in the tool, and who only ever needed the data.
Types of audits and migrations we run
CRM to CRM
Before you move a CRM you need to know which fields are load-bearing and which are ten years of abandoned experiments. Rig audits the org against real usage, flags the dead fields and the schema bloat, and shows you the automation debt a previous integrator left behind.
Where that logic belongs in the warehouse rather than the CRM, it moves there first, so finance flows keep working through the cutover. Then we map, dry run, and migrate.
Merging two data estates
Two companies, two of everything, one platform at the end of it. The hard part is never the copy. It is deciding which of the two CRMs survives, what happens to ten years of finance history in the one that does not, and in what order flows can be cut over without breaking month end.
Rig gives you an estate map scoped by legal entity, a fate for every system, and a sequence built on what actually depends on what. Definitions get aligned once, in the context layer, and applied retrospectively so reporting survives the merge.
We also do warehouse replatforms and semantic layer moves, including importing metric definitions that already exist rather than making someone retype them.
How the engagement works
Audit and plan
We connect the sources, build the map, and come back with the systems map, the drop list, the mapping document and the proposed phases of work. From the day we get access to source data, whether that is a live connection or flat files, the audit plan comes back inside the first fortnight of access.
Dry run and migrate
Scoped off the back of the audit, so you are agreeing to a plan you have already read. We dry run it, you sign it off, and then it runs: with you, for you, or alongside the integrator you already have.
Priced per engagement. The software carries on afterwards on a normal subscription, so the map and the context layer keep working once the migration is finished.
What you get, and the guardrails around it
- An editable systems map
- An integration flow graph
- A downstream impact map for any field or process
- A ranked list of drop candidates, with evidence
- A seat and licence usage review
- Coverage views, source to destination
- Column-level source and target diffs
- A semantic layer rebuilt on the destination
- A dry run report
- Nothing executes against a live system until it has been signed off and dry run.
- Every mapping is reviewed by a human before it ships.
- Access starts read-only and least-privilege. Elevated permissions are granted for the phase you approve, and revoked after it.
- Role-based access control and PII masking on the context layer, with a full audit trail on every write.
- Plain tables in your own warehouse. No proprietary formats, so leaving is as easy as arriving.
The access pattern is written up in full, including which permissions are needed for a read-only audit and which are only granted for the phase you approve. Read the Salesforce access guide.
What we plug into
And 100+ more.
Common questions about migrations
Yes, and plenty of engagements start there. You get the evidence base and a prioritised path out of it, and you decide afterwards whether there is a migration at all.
No. The CRM is usually the heart of it, but the audit covers the estate around it: ERP, finance, the warehouse, and the integrations between them.
It depends on the size of the estate, but the shape is consistent. From the day we get access to your sources, the audit plan comes back within two weeks. The migration itself is a second phase, scoped off the back of that plan, and measured in weeks rather than months. We will tell you on the call if we think yours is the exception.
Either, and often both. Some clients want us to execute. Some want the map, the plan and the dry run, then run the cutover with their own team. Some already have a systems integrator who executes against what we produce. The audit phase is the same in all three cases.
Not necessarily. Mapping, auditing and dry running are the parts Rig makes dramatically faster, and they are also the parts most likely to be wrong when they are done by hand. Plenty of engagements end with an integrator executing a plan that Rig built and validated.
This is the question that decides most mergers. Definitions are aligned once in the context layer and can be applied retrospectively, so a metric means the same thing either side of the move. Anything that genuinely cannot be reconciled is flagged during the audit rather than discovered after cutover.
No. The first version of the map is built from synthetic samples of the schema. When real data is needed, access starts read-only and least-privilege, and elevated permissions are granted only for the phase you have approved.
No, and be wary of anyone who says they can. Rig maps the estate, proves what is actually used, and validates that answers still match after the move. Converting the SQL itself is work our team does with you, informed by that map.
Often yes. Where definitions already exist in a modelling or BI layer, we import them and map each one to a Rig metric with its SQL, joins and description intact, rather than making someone retype them. Where they only exist in people's heads, the audit is how they get written down.
That is the normal state for a platform that has just been stood up. Rig profiles the warehouse directly, value-tests joins against real key overlap, proposes metrics and validates them against the data, then drafts a context layer for your team to curate.
Merging two estates, or moving off one?
Tell us what you're moving. We'll scope the audit on a call.