How a database project runs from first call to handover
The engagement model at HORIZONIS HOLDINGS BV: discovery, a written technical assessment, phased delivery, handover you can run yourself, and support that ends when it stops being useful.
Orientation
Engagements that justify themselves every phase
This page sets out the engagement model at HORIZONIS HOLDINGS BV: what happens during discovery, how a technical assessment is produced, how delivery is phased, what handover looks like and what support continues afterwards. It also covers how GDPR-aware data handling and security practices are applied throughout a database project.
The structure is deliberate. Most database projects fail not because of the engine, but because no one wrote down what the estate actually does before touching it, because delivery was a single irreversible event, or because handover was left to the last day. Each of the acts below describes how we avoid that.
You can start reading anywhere, but the sequence matters: each act depends on the one before it.
Where we start
A one-hour conversation about what exists and what has gone wrong.
What you get first
A written technical assessment you can hand to your own engineers.
Where we end
Handover, with recovery procedures that have been run at least once.
The seven acts
From the first conversation to the record of what was decided
Read this as an elevation of the rack: each row is one phase, and the row you are on is the one we would be working on with you.
Discovery
Discovery and the first conversation
An engagement starts with a conversation, not a proposal. We ask what systems exist, who operates them, what has gone wrong recently and what would need to be true for next year to be easier than this one. That conversation usually lasts about an hour and does not require preparation on your side — bring whoever knows the systems, and nothing else.
The questions are the ordinary ones asked carefully. Which engine is doing most of the work, and on whose behalf. Who receives the alerts and whether those alerts have ever fired in anger. What the last incident actually was, and what it cost in hours. Where the report that someone senior asks for every Monday is actually built.
By the end of it we can say whether the problem is one we should take on. Sometimes it is not. A question that turns out to be an application architecture issue, or one where an internal team already has the capability, gets told so rather than converted into a project. That is the point of spending the hour before any paper is signed.
Assessment
The technical assessment
Before any code is written, we produce a written picture of the current estate. It is meant to be read by engineers and by whoever signs off on the work, and it is written so that both can act on it without a translator.
The engines in use
Which database management systems you actually run, at which version and in which environment. Frequently more than the signed architecture diagram admits.
The workloads they carry
Which service depends on which instance, what a normal day looks like against what a bad day looks like, and which queries are responsible for the difference.
Backups and recovery, as they really work
Not the schedule that runs, but the age of the oldest untested backup. The two numbers are often very different, and only one of them survives an incident.
Where personal data lives
The columns and tables that hold identifiers, and every copy of those columns: backups, reporting extracts, development environments, analytics dumps.
Index coverage against real query patterns
What the indexes were designed for versus what the queries actually ask. Most slow databases are not under-resourced; they are indexed for a workload that has drifted.
Replication behaviour under load
Lag, failover, and what the readers see when the primary is busy. Tested rather than assumed, because replication that has never been failed over is a hypothesis.
The assessment is not a sales document, and it does not lead with recommendations for the work we would like to be paid for. Sections that found nothing worth changing say so.
Phasing
Scoping and delivery phases
Work is broken into phases with a defined result at the end of each one. A phase might be a schema redesign, a monitoring rollout, a migration rehearsal or the first release of a management component. Each phase ends with something you can inspect and use.
A migration, phase by phase
- Rehearse Rehearsal on a copy of production, timed against a real workload rather than the migration script's own estimate.
- Verify Row counts, checksums and application smoke tests, agreed before the rehearsal so nobody is arguing about what 'working' means during the cutover.
- Cut over A short, rehearsed window where rollback is a decision someone can actually take, not a paragraph in a plan.
- Settle A defined period after cutover where we watch the same metrics the assessment recorded, side by side, and close out the difference.
Th