Cloud & Infrastructure Consulting
Migrations rarely fail on the technology. They fail on the things nobody wrote down: the batch job that assumes a local mount, the licence tied to a MAC address, the report someone runs on the last day of the quarter. We spend the first weeks finding those, then move the estate in an order where every step is reversible and the cutover itself is the least interesting part of the project.
Before anything moves we build a real inventory: what runs where, what talks to what, and what the actual dependencies are rather than the ones on the architecture diagram. Application grouping, data gravity, licensing constraints and compliance scope all come out of this, and they determine the order everything else happens in.
Rehost, replatform, refactor or retire, decided per application rather than as a programme-wide policy. Lift and shift is right for some things and an expensive mistake for others. We say which is which, and what each choice costs you later in running expense and engineering time.
Oracle, SQL Server, PostgreSQL, MySQL and MongoDB moved to managed services or to instances you keep control of. Schema conversion, change data capture for near-zero downtime cutover, replication lag monitoring, and a rehearsed rollback. We test the restore, not just the backup.
Terabytes to petabytes, moved on a schedule that fits your window. Online replication where the link allows it, physical transfer appliances where it does not, and object storage lifecycle design so the landing point is not simply a more expensive version of the filer you left. Integrity is verified on arrival, not assumed.
Most migrations run hybrid for months. Private connectivity, DNS that resolves consistently on both sides, identity federation so people do not hold two sets of credentials, and monitoring that spans the gap. Built to be dismantled cleanly once the last workload lands.
A runbook with named owners, decision points and a rollback that has actually been rehearsed. Then we stay for the period afterwards, when the real problems surface: the cost that is higher than modelled, the job that only runs at month end, the permission nobody needed until now.
Common questions
Discovery is usually two to four weeks and gives you a defensible plan and cost model. Execution depends on estate size and how much has to move together, from a few weeks for a single application to many months for a datacentre exit. We would rather give you a real number after discovery than a comfortable one before it.
Near-zero downtime is achievable for most engines using change data capture and replication, with a cutover measured in minutes rather than hours. Genuinely zero downtime depends on the engine, the application's tolerance for a brief read-only window, and whether the schema changes. We tell you which category you are in during discovery.
Usually both, applied to different workloads. Refactoring everything stalls the programme, and refactoring nothing moves your problems into a more expensive place. We assess per application and give you the running cost of each option, so the decision is financial rather than ideological.
It depends on volume and the window. Online replication over private connectivity where bandwidth allows, physical transfer appliances where it does not, and a staged approach for anything that must stay available throughout. Integrity is verified on arrival with checksums, and the source stays intact until you have signed off.
Licensing is one of the first things discovery examines, because it frequently changes the economics of a move. Some licences transfer, some are cheaper as a managed service, and some are the reason a workload should be replatformed rather than rehosted. You get that picture before committing to an approach.
Also from us
Contact
A few lines is enough. We will come back with an honest view of whether we are the right people for it.
