Highveld Provincial e-Services, a fictional provincial service platform, began with one department and one service: online applications for a business trading licence. The pilot ran in a single subscription that the developers created themselves, outside the province's landing zone and without its guardrails, used one web app and one database, and was supported by the three developers who built it. Eighteen months later the same platform carried services for four departments, accepted submissions from twelve delivery partners, synchronised with on-premises records in two district offices and was mentioned in the provincial budget speech.
The architecture had changed in that time, but mostly by accretion. A second department's service was added to the same subscription because that was quicker. A partner integration went in as a direct API call because the queue was "phase two". Backups existed, but nobody had restored one. When a schema migration for one department's service failed halfway and left the shared database unusable for forty minutes, three departments learnt at the same moment that they shared a dependency.
This article sets out how an Azure architecture should change as a platform moves from pilot to production service to critical platform, what triggers each move, and who owns the changes. It builds on part 1, which described the twelve decision layers; here the question is how the answers in those layers should change over time.
Three stages, defined by consequence
The stages are not about size. They are about what happens when the platform fails.
Pilot. Limited users, synthetic or low-sensitivity data, a manual fallback that works. Failure is an inconvenience. The goal is learning, and the architecture should be cheap to change.
Production service. Real citizens and officials depend on it for a defined service, personal information is processed, and the manual fallback is slow or costly. Failure is a service incident with a named owner.
Critical platform. Several departments or partners depend on shared components, the service is publicly visible, and some functions have no practical manual fallback. Failure affects many services at once and becomes a provincial matter.
The move between stages should be triggered by evidence, not by a project plan. Highveld now uses five triggers: a second department joining, personal information of a new category being processed, an external partner integrating, a recovery objective being stated in a service agreement, or public visibility through a ministerial or budget announcement. Any one of them opens a stage review.
What changes in selected layers, plus ownership and cost
| Layer | Pilot | Production service | Critical platform |
|---|---|---|---|
| Landing zone | A workload landing zone with platform guardrails, even for the pilot | Separate environments by subscription; policy enforced | A workload landing zone per department service, grouped and owned by department; shared components in their own subscription with their own owner |
| Identity | Entra ID for staff; simple citizen sign-in | Managed identities between services; privileged access reviewed | Separate administrative roles per department; break-glass accounts tested |
| Edge | One public entry point with a web application firewall | WAF rules tuned; DDoS posture decided | Shared edge with per-service routing and rule ownership |
| Network and hybrid | Site-to-site VPN if on-premises data is needed | Hub network; private endpoints for data | Resilient hybrid connectivity; documented failover of the hybrid path |
| Integration | Direct calls acceptable | Queues for partner submissions | Event contracts versioned; per-partner throttling and dead-letter handling |
| Data | One database | Backups with retention matching policy | Per-department data ownership; restore drills; analytics separated from transactions |
| Observability | Basic logs and alerts to the team | Service-level objectives and on-call | Cross-service tracing; a platform-level view for shared dependencies |
| Recovery | Rebuild from code | Recovery objectives defined and tested | Recovery tested per failure scenario; region position stated |
| Delivery | Pipeline with infrastructure as code | Approvals and environment promotion | Change windows for shared components; policy as code |
| Cost and ownership | One budget | Per-service cost reporting | Shared-cost allocation agreed between departments |
Two things stand out. First, some decisions should be made correctly from the first day, even in a pilot, and Highveld's pilot did not make them: a workload landing zone with the platform's guardrails, Entra ID, a single inspected entry point and infrastructure as code. They cost little at the start and a lot to retrofit. Second, most of the expensive changes are about ownership and recovery rather than about adding services.
Microsoft's Cloud Adoption Framework describes the platform and workload landing zone split (checked on 5 November 2026), with each workload landing zone holding that workload's development, test and production environments. Microsoft's model is one workload landing zone per workload, so Highveld gave each department service its own and grouped them by owning department at the critical stage. Before then, putting four departments' services in one subscription had made it impossible to give each department control over its own changes without giving it control over everyone else's. The shared network that the departments now plug into follows the hub-and-spoke ownership model described in Enterprise landing-zone networking.
The responsibility matrix
Most of Highveld's incidents in the first eighteen months were ownership failures, not technology failures. The platform's architects now publish a responsibility matrix as part of the architecture, not as an appendix.
| Capability | Provincial platform team | Department service team | Delivery partner | Service owner (business) |
|---|---|---|---|---|
| Management groups, policy and guardrails | Owns | Consulted | Informed | |
| Hub network and hybrid connectivity | Owns | Consulted | ||
| Shared edge and WAF baseline | Owns | Owns service-specific rules | ||
| Workload subscriptions and resources | Provides | Owns | Accountable for spend | |
| Partner API contracts | Consulted | Owns | Complies | Approves changes |
| Service-level objectives | Advises | Owns measurement | Sets the target | |
| Restore and recovery testing | Owns platform components | Owns service data | Accepts the residual risk | |
| Personal information processing | Provides controls | Owns processing records | Processes as an operator under a written contract | Accountable, for the province as responsible party |
The personal information row uses the terms of the Protection of Personal Information Act: the province is the responsible party and has an information officer, and a delivery partner that processes personal information on its behalf is an operator, which section 21 requires to work under a written contract with security measures. This is general information, not legal advice.
The matrix is a decision artefact. When a department asks for a firewall exception, the matrix says who decides. When a restore fails, it says who should have tested it.
Failure and recovery, proven rather than assumed
At the critical stage, recovery cannot be a line in a document. Highveld lists its failure scenarios and, for each one, how it is detected, who recovers, the recovery objective and when it was last tested.
The scenarios include loss of a single database, loss of the hybrid connection to a district office, a failed deployment of a shared component, compromise of an administrative account, and loss of the primary region. Each has a different answer. The hybrid link, for example, is protected by letting district offices queue updates locally and synchronise when the link returns, which is cheaper and more reliable than a second link for most offices. Hybrid and multicloud without architecture theatre explains why a hybrid design should be justified by a real constraint, as this one is.
The region scenario needs a deliberate position. When Azure is the right answer explains the South African caveat: availability zones protect against a data-centre failure, not a regional one, and a second region raises questions of capacity, latency and data residency. Highveld's position is written down: transactional services recover within the primary region across zones, a nightly copy of critical records is held in a second location under the province's data residency rules, and full regional failover is not offered for the pilot-era services. A position someone has decided and written down is better than an assumption.
Microsoft's Well-Architected Framework includes mission-critical workload guidance for services expected to be always available. Most provincial services do not need that level, and designing every service as mission-critical is an expensive way to avoid deciding. Use it for the few functions that genuinely need it.
Observability at each stage
A pilot needs logs and alerts that reach the team. A production service needs service-level objectives that the service owner has agreed, and an on-call arrangement. A critical platform needs one more thing: a view of shared dependencies, so that an incident in a shared component is recognised as a platform incident within minutes rather than as four separate service incidents. Logs, metrics and traces when production breaks covers the signals; the architectural decision is which shared components get platform-level monitoring, and who watches it.
Cost and ownership
At the critical stage, shared costs need an allocation rule that departments have agreed to before the invoice arrives. Highveld allocates shared edge, hub and monitoring costs by request volume and stores the rule beside the responsibility matrix. Cloud cost governance covers the wider practice.
A stage review checklist
Run this whenever a trigger fires.
- Which stage is the platform in now, and which trigger moved it?
- Which decisions from the table above are below the new stage's standard?
- Does the responsibility matrix name an owner for every shared component?
- Has each recovery scenario been tested within its agreed interval?
- Is the region position written down and accepted by the service owner?
- Are shared costs allocated by an agreed rule?
Key points
- Pilot, production service and critical platform differ by the consequence of failure, not by size.
- Move between stages on evidence: new departments, new data categories, partners, stated recovery objectives or public visibility.
- Get a few things right from the pilot onwards: workload landing zone, Entra ID, one inspected entry point and infrastructure as code.
- At the critical stage, most of the work is ownership and recovery: a responsibility matrix and tested failure scenarios.
- State the region and recovery position explicitly, and reserve mission-critical design for the functions that need it.
Next: Part 3, Foundry or Copilot Studio? Start with the operating model. All parts are on the series page.
How CloudNala can help
CloudNala helps public-sector and enterprise teams plan how an Azure platform should grow. We assess which stage your platform is really in, identify the decisions that lag behind it, build the responsibility matrix with your platform and service teams, and design and run the recovery tests that turn a recovery plan into evidence, so that the platform's architecture keeps pace with what people depend on it for.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Azure Architecture Review or write to us at consult@cloudnala.co.za