Data engineering · Platform and migration
A platform sized to the business, not the brochure
Choosing and building the analytical platform, with layout, environments and running cost designed in from the start, then moving the existing reporting estate onto it without breaking anyone’s numbers along the way.
Where this starts
Chosen on features, regretted on cost
Analytical platforms are usually selected on a feature comparison and a demonstration, then judged eighteen months later on a bill nobody forecast and a structure nobody designed. Compute left running overnight, every team building its own copy of the same tables, no separation between experiments and the figures the board reads. The platform is rarely the wrong choice. It was adopted rather than engineered.
What we usually find
- A platform bill growing faster than the data it holds
- No separation between experimental work and the board’s figures
- Every team maintaining its own copy of the same core tables
- An ageing reporting database nobody dares to switch off
- A migration planned as a single cutover weekend
- Figures that changed after a move, with nobody able to say why
Our position
The cheapest analytical platform is often the one you already own, run properly. We will say so before we recommend another.
What the work covers
Designed first, then moved
Structure comes first, because the layout decided in the first month sets the running cost and the maintenance burden for years afterwards.
Platform selection
A decision made against your volumes, query patterns, skills and budget rather than a feature matrix, and one that includes the option of staying where you are.
Layered structure
Raw, cleaned and modelled layers kept apart, so a source can be reloaded without disturbing the figures built on top of it.
Separate environments
Development kept apart from production, so experimental work never touches the figures leadership is reading that morning.
Cost by design
Storage and compute sized to how the platform is actually queried, with automatic suspension and budgets, rather than provisioned for a peak that never arrives.
Access by role
Who can read and change what, set by role from the first day. Protection of sensitive data belongs to data security and is wired in rather than rebuilt here.
Moving the reporting estate
Existing reports and their logic moved across in groups, with old and new figures reconciled side by side before anything old is retired.
How the move stays trustworthy
The numbers match before anything is retired
A platform migration is judged on one thing: whether the figures people rely on are the same afterwards, or different for a reason somebody can explain.
Usage audit
Every report and table on the old estate measured for use before the move, so the ones nobody opens are retired rather than carefully migrated.
Parity
Key figures computed on old and new platforms and compared automatically, with every difference explained and signed off before cutover.
Cutover
Reports moved in groups, each signed off by the people who use it, so no single weekend carries the whole risk of the programme.
Cost guard
Budgets, alerts and automatic suspension, so an expensive query or a forgotten job is noticed within a day rather than on the invoice.
Switch-off
A date for turning the old estate off, agreed at the start and held to, with the licence and hosting saving recorded when it lands.
What you are left holding
- A platform chosen against your own volumes and budget
- Separate raw, cleaned and modelled layers
- Development and production kept apart
- Parity checks proving the figures match
- The old estate switched off on an agreed date
Tell us what the current platform costs and who uses it
Those two figures usually decide whether you need a new platform or a better-run one.