Data and integration
Get your data out, and keep the seams working.
Extraction from the incumbent SaaS, schema mapping and reconciliation, an event backbone, and the integrations that made the old tool sticky — rebuilt natively so they are yours too.
The premise
Two problems that look different and are the same problem. Getting your data out of a product you are leaving, and keeping the seams working afterwards. Integrations are what make a licensed product sticky, and the reason a replacement stalls is almost never the application — it is the nightly job nobody owns that feeds the finance system.
What you get
- A full extraction from the incumbent, including the parts the vendor export does not cover, with the method documented so you can run it again.
- A schema mapping from source to target with every transformation written down and every dropped field justified in writing.
- A reconciliation report that counts records, checks totals and lists every mismatch by class — run on the dry run, run again at cutover, kept as an artefact.
- An event backbone so systems integrate through published events rather than point-to-point calls that nobody can find later.
- The integrations that mattered, rebuilt natively: identity, the finance feed, the data warehouse load, the two webhooks holding a business process together.
- Idempotency, replay and a dead letter path, because integrations fail at three in the morning and somebody has to be able to fix it without you.
- Contract tests on every seam, running in CI, so the next change to either side breaks a build rather than a month-end.
How it runs
5 phases, each with a date attached.
Durations below are what this shape of work typically takes with a team of two to four. They move with scope, and the assessment is where they stop being typical and start being yours.
- 01
Seam inventory
1 to 2 weeksEvery integration in and out of the system being replaced, including the ones not in the architecture diagram. Network logs and vendor audit logs are more honest than documentation here, and we use both.
- 02
Extraction and mapping
2 to 3 weeksBuild the extraction, write the mapping, and produce a first reconciliation against a real snapshot. Expect this phase to find the encoding problem, the soft-deleted records and the field two teams use for different things.
- 03
Integration build
3 to 5 weeksThe backbone and the rebuilt seams, each with contract tests and a replay path. Sequenced so the highest-risk integration is done first, not last.
- 04
Dry run and reconciliation
1 weekThe complete migration against production-shaped data, timed, with the reconciliation report reviewed line by line with your data owners. The output of this phase is the cutover window estimate you can actually plan around.
- 05
Cutover support
Cutover weekend plus 2 weeksWe run the migration with your team watching, hold the rollback decision open until the reconciliation passes, and stay for the first month-end.
What it costs
No rate card on this page, on purpose.
Usually bought as part of a replacement rather than on its own, and priced inside those phases. Where it is bought standalone — a data extraction from a product you are leaving regardless, for instance — it is priced per phase like everything else.
The honest cost driver is data quality, and nobody knows their own data quality before the first extraction. That is exactly why the dry run exists as a separate phase with its own price: it is the cheapest way to find out whether the migration is a week or a month, and it happens before you have committed to a cutover date.
If the incumbent charges for API access or export volume above a threshold, that cost is yours and we will find it in the seam inventory rather than in the invoice.
A published day rate would be a number we could not stand behind for your specific situation, and every firm that publishes one quotes something different in the room. What we will commit to before you sign is the phase scope, the phase price and the team shape. Use the calculator for the replacement arithmetic against your own seat count.
Normally bought inside
Join
Hire a Forward Deployed Engineer. They sit in your team.
Monthly per engineer. 3-month minimum, 30-day exit.
Deliver
We take it end to end and hand over the keys.
Fixed price per phase. Run priced separately.
When not to buy this
3 reasons to walk away.
Every library entry has rows where the honest answer is no. Every service page has this section for the same reason: the cases below are ones we have seen go badly, and we would rather lose the work than deliver into them.
You want a warehouse, not a migration
Building an analytics platform is a different discipline with different tooling. We do the operational data plane and the seams between systems. For a data warehouse programme, hire a data team.
The incumbent contract blocks the export
Some agreements restrict bulk extraction or charge punitively for it. Read the contract before you buy this — occasionally the honest answer is to wait for renewal, and it is better to know that in week zero.
Nobody will own the data model afterwards
A migration produces a schema and a set of decisions about what your entities mean. Without a data owner, that decays quickly and you will be paying somebody to rediscover it in two years.
Pick one contract. We will show you the replacement.
A two-week assessment: we take your single most expensive SaaS line item, establish what you actually use, and come back with a parity matrix, an architecture for AWS and Azure, a cost model and a delivery plan. Fixed price. If the answer is keep buying it, we will tell you that.