Digital transformation consulting is a category that has lost most of its meaning over the last decade. The label gets attached to everything from "swap your Excel for a SaaS subscription" to "replatform your entire core banking stack". The result is that an operator commissioning a transformation engagement often has no shared definition with the consultant about what is actually going to be delivered, on what timeline, against what budget envelope, and with what handover at the end.
What we mean by consultation, and what we do not
Zeour's digital transformation consultation service is a specific, scoped engagement. It is not a strategy deck. It is not a year-long retainer. It is not a re-org plan. It is a fixed-fee Discovery engagement that produces three concrete artefacts the operator can act on:
- 1A current-state map. What systems the operator actually runs today, where they sit (on-prem, hosted, SaaS, owned-and-abandoned), how they talk to each other, where the data lives, where the manual workarounds are, and which integrations are load-bearing versus which are decorative. This usually surfaces between 30% and 60% more shadow systems than the IT inventory claims exist.
- 2A target-state architecture. Not a vision-statement. A specific architecture diagram showing which systems stay, which get retired, which get replaced, which new systems are introduced, what the integration map looks like, and where the data sovereignty and regulatory perimeters land. Costed at component level.
- 3A sequenced delivery roadmap with a credible fixed-fee Build estimate. Phased — typically four to eight phases — with each phase delivering operator-visible value, each phase scoped to a fixed fee, and the dependency chain explicit. The operator can pick up the roadmap and either run the Build with us or hand it to another partner. Both options are intentional.
What the consultation does not produce is a glossy 80-page report that gets shelved. We have seen enough of those.
Why operators run consultation as a distinct phase
The operators who get the most out of running consultation as a distinct upfront phase tend to share three characteristics. They have either inherited a complicated estate (often through M&A) and need an honest map before they commit to a Build budget. They have been burned previously by a transformation engagement that over-promised and under-delivered, and want a scoped commitment from a delivery partner before they commit to a long-term engagement. Or they are operating in a sovereignty-sensitive sector where the architecture has to be defensible to a regulator, and they need a credible architect to author the target-state document.
In each case, the cost of skipping Discovery is asymmetric. A bad architecture choice in week 2 of a 40-week Build engagement becomes visible in week 28 and costs 5–10x to unwind. A clean Discovery upstream of the Build is the cheapest insurance the operator can buy.
What a typical engagement looks like
A typical Zeour Discovery engagement runs 3 to 5 weeks at a fixed fee, depending on the size of the operator's estate. The shape is consistent:
- Week 1 — workshops with the operator's leadership, IT, operations, and compliance functions. We sit with the COO, the CTO or CIO, the operations leads, the head of compliance or data protection, and the heads of the customer-facing functions. We do not interview by questionnaire; we run working sessions where the conversation gets explicit about what works, what does not, and what the operator wishes was different.
- Week 2 to 3 — system inventory and integration mapping. We walk the IT estate. We map the data flows. We identify the shadow systems. We document the regulatory perimeters. This is unglamorous work and it is where most of the engagement value is generated.
- Week 3 to 4 — target-state architecture and roadmap drafting. We translate the current state into a target architecture, prioritised by operator-stated value, and we sequence the roadmap into phases with fixed-fee estimates and explicit dependencies.
- Final week — delivery and walkthrough. We present the artefacts to the operator's leadership, run a question-and-answer session, hand over the source documents in editable form, and end the engagement.
The operator owns everything the engagement produces. There are no consultant-only artefacts. There is no lock-in to a follow-on Build engagement — if the operator wants to take the roadmap to another partner, the roadmap is written to be readable by another partner.
Where we focus the architecture conversation
The target-state architecture conversations we end up having most often, in roughly descending order of frequency:
- Data sovereignty and where the workloads should run — on-prem vs hosted vs SaaS, and the regulatory implications of each per jurisdiction the operator runs in.
- Multilingual and localisation posture — English and Arabic (full RTL) baseline if the operator runs in a market where that is operating norm, with French, Spanish, German, Portuguese, Italian, Dutch, Turkish, Urdu, Hindi or other locales added per engagement scope.
- On-premises AI — whether the operator can run open-weight LLMs (Llama 3.x, Mistral, Mixtral, Qwen, DeepSeek) on owned hardware via vLLM, Ollama, or TGI, with RAG against the operator's own knowledge base, instead of routing prompts to a third-party API. For sovereignty-sensitive operators this is increasingly the answer.
- Integration surface — REST, webhook, message-queue, file-drop — what shape of integration the operator's existing systems already speak, and what new shape the target architecture should standardise on.
- Operate-and-exit model — whether the operator wants to operate the resulting estate themselves at the end of Build, or stay on a Care Plan tier. We design for either.
None of these conversations are theoretical. They each map to specific architecture decisions in the target-state document.
What happens after Discovery
The operator owns the roadmap. If they want to run the Build with us, we move into a fixed-fee Build engagement against the Discovery roadmap — typically 12 to 40 weeks of milestone-fixed delivery with weekly demos, change-order discipline, and a Pilot phase before Rollout. The Operate phase that follows is either an ongoing Care Plan or a self-sufficient operator at the end of the 90-day exit window. The whole engagement model is designed so that the operator's worst-case outcome is owning a clean, well-documented system on their own perimeter, with the keys, the repository, and the runbook.
If the operator wants to run the Build with another partner, the Discovery artefacts are written to be portable. The architecture document, the integration map, the phased roadmap — all editable, all handed over.
What the Discovery does not do
It is worth being explicit about the things Discovery does not include, because operators sometimes arrive expecting otherwise.
It does not include implementation work. The output is artefacts the operator can act on, not deployed systems.
It does not include a sales pitch. The architecture document recommends what is right for the operator, including recommending tools or partners other than Zeour where that is the honest answer. We have written Discovery roadmaps that recommended specific best-of-breed components from other vendors because they were the right fit, even when the operator was actively considering us for the Build.
It does not include a multi-year transformation strategy. Discovery scopes the next 12 to 24 months of practical work. Multi-year vision exercises are a different kind of engagement and we do not run them — there are large consulting firms that do, and they are better positioned for it.
It does not include a re-org plan. The architecture conversation touches on operating-model implications (where the operator will need new roles, where existing roles will shift), but org-design is not the scope of the engagement.
What the Discovery does include is a credible, costed, sequenced answer to the question "what should this operator actually build over the next 12 to 24 months, in what order, against what budget, and with what regulatory posture". The operator can take that answer and run with it — with us, with another partner, or in-house.
The Discovery engagement is a scoping call away. We do not pre-write proposals; we run the call, understand the scope, quote a fixed fee, and start when both sides agree.
