BLUEHARBOURD2
Book an intro call

Depth 20 · Service line

Cloud, data and modernisation

Cloud, data and modernisation is the work of moving a company's systems and data onto infrastructure it can maintain, organising data so it can be trusted for decisions, and retiring old systems once their replacements are proven. It is slow, careful work, because the systems involved usually carry the business while it happens.

Inside this line

Three sub-services: migration, data platform and legacy retirement.

Input
An inventory of the systems and data in scope, current hosting and licence arrangements, and the people who know how the old systems really behave.
Method
We document what exists before changing anything, move or rebuild in stages that can each be reversed, and compare old and new outputs side by side before any switch.
Deliverable
Systems and data running on the agreed platform, infrastructure written as code in your accounts, and a record of each stage with its verification.
Measured by
Outputs of old and new systems matched on agreed checks, data reconciliation reports, and incidents during each cutover.

Level 3 · 01

Migration

Migration is moving an application, its data and its configuration from one environment to another, such as from an owned server to a cloud account or between cloud providers. Some systems move largely as they are, others need changes to run well in the new place. The decision is made system by system.

Inside it

  • Dependency inventory
  • Move as is or adapt, decided per system
  • Rehearsal in a production copy
  • Cutover with rollback ready
  • Infrastructure as code in your accounts

Measured by Reconciliation reports for data, matched behaviour on agreed test cases, and incidents during and after cutover.

Migration, full page

Level 3 · 02

Data platform

A data platform is the set of tools that collects data from a company's systems into one place, cleans it and shapes it into tables people can query and trust. The central part is usually a data warehouse with a modelling layer: written, tested definitions of what a customer, an order or revenue means, so two reports never disagree because they counted differently.

Inside it

  • Ingestion from source systems
  • Data warehouse setup
  • Version controlled data models
  • Data tests and freshness checks
  • Glossary of business definitions

Measured by Model tests passing on each run, data freshness against the agreed schedule, and reports that reconcile with source systems.

Data platform, full page
Deliverable · Level 4→ Warehouse and modelling layerWarehouse and modelling layer: ingestion pipelines, tested models in your repository and a glossary of business definitions.

Level 3 · 03

Legacy retirement

Legacy retirement is switching off an old system safely once something else does its job. For a period the replacement runs alongside the old system, and both are compared on the same work. The old one is switched off when the evidence shows nothing still depends on it, not when a date in a plan arrives.

Inside it

  • Dependency tracing from logs and interviews
  • Parallel running with result comparison
  • Moving users across in groups
  • Archiving data that must be kept
  • Shutdown on evidence of no remaining use

Measured by Remaining dependencies in the register, differences found in parallel runs, and requests to the old system recorded in its logs.

Legacy retirement, full page

Where this applies

Who this is for: CTOs and data leads with systems on ageing hosting, data spread across tools, or a migration that keeps being postponed.

Sectors this line is set up for, not a list of clients.

Payments and fintechIND 01
Moves between hosting platforms with reconciliation reports that show every record arrived.
LogisticsIND 04
A warehouse layer that joins order, carrier and finance data into one model.
B2B softwareIND 02
Retirement of legacy services once their traffic and data have moved.
EcommerceIND 05
Reporting tables that answer margin and stock questions without manual exports.

Shape of the work

01Inventory source02Copy data03Reconcile04Switch traffic05Parallel run06Retire source
Migration path: inventory the source, copy data to the target, reconcile counts and checksums, switch traffic, run both in parallel, then retire the source.

What you get

  • 20.1 · MigrationEach system running in the target environment, defined as code, with a cutover record and a tested rollback step.
  • 20.2 · Data platformWarehouse and modelling layer: ingestion pipelines, tested models in your repository and a glossary of business definitions.
  • 20.3 · Legacy retirementA dependency register, parallel run reports, an archive of the data you must keep, and a shutdown record.

What we work with

Languages and runtimes
TypeScript · JavaScript · Node · Python · Go · SQL · Bash
Back end and APIs
REST · GraphQL · webhooks · background workers · queues
Data
PostgreSQL · pgvector · Supabase · Redis · dbt · BigQuery
Automation
n8n · scheduled jobs · event driven triggers
Cloud and delivery
Vercel · Cloudflare · AWS · Google Cloud · Docker · Terraform · GitHub Actions

These are the tools we work with, not partnerships, certifications or resale agreements.

How this fits the other lines

When this is not the right line

If the current system works, is supported and costs what you expect, moving it adds risk with no return. If you need a vendor to resell cloud capacity or licences, we do not do that.

Questions about this line

Can the old and new systems run side by side?
Yes, and for most migrations we recommend it. Both run in parallel while reconciliation reports compare their records, and the old system is switched off only after you sign off that comparison.
Will there be downtime when we move?
Sometimes a short planned window is the honest answer, and sometimes a system can be moved with none. We decide per system once we know how it stores data, and agree the window with you in advance rather than discovering it on the night.
Which cloud provider do you recommend?
We have no reseller arrangement with any provider. The recommendation follows where your team has skills, where your data must legally sit and what the systems need, and it is written down with the reasons.
How do we know the data arrived complete and correct?
By reconciliation: counting records and comparing totals and samples between the old and new systems for every table that matters, and keeping the reports. A migration is not signed off on a visual check.

List what has to move

Name the systems and data stores you want moved or joined, and what cannot go down. We reply with the order we would move them in.

List the systems

An email exchange first, no call needed.