Onboarding: Getting Your Application Onto the Platform

This is the typical path from an idea to a production spoke. The exact steps, forms and approvers belong to your organisation. The path below combines the platform's technical steps with the governance steps that organisations usually add. Ask your platform team for the onboarding form and the intake channel.

flowchart LR
    A["1. Register"] --> B["2. Technical onboarding<br/>(dev spoke)"]
    B --> C["3. Privacy and data review"]
    C --> D["4. Design"]
    D --> E["5. Security check"]
    E --> F["6. Production spoke<br/>and go-live"]

Step	What you do	What you get
1. Register	Describe what you want to build or move. Name a product owner (end responsible) and a technical contact. Read the responsibilities and limits and agree to them. Make sure the people who will deploy have a managed device and network access (for example VPN) to reach private resources.	A conversation with the platform team about fit and next steps
2. Technical onboarding	Complete the technical part of the form: workload short name (max 6 characters), environments, subscription, address-range size, subnets, team group, tags, data classification, budget and any registration your organisation requires (for example a CMDB entry). See How to request.	A dev spoke to start building in
3. Privacy and data review	Decide whether your application processes personal data. If it does, do the privacy assessment (for example a DPIA) and talk to data management. This sets the pii tag.	A recorded privacy outcome
4. Design	Draw the architecture: Azure resources, connections to other systems, the access model (Entra ID groups), special requirements. Add the resources the baseline already gives you (see What you get) and the ones your application needs. Consider the availability and recovery of each component. Ask for a design review.	An approved design
5. Security check	Provide the classification (confidentiality, integrity, availability). Review the risk analysis. Extra measures may be required, such as a penetration test or design changes.	A security approval or a list of conditions
6. Go-live	Request the production spoke. Deploy through your pipelines. Use your checklist. For substantial changes later (new data types, many more users, new functionality), consult the platform team: a new review may be needed.	A prd spoke

Do it in parallel

The dev spoke in step 2 lets you start building while steps 3 to 5 are in progress. Only the production spoke waits for approvals.

Have this ready

A request is handled fastest when you can answer these questions up front.

Item	Why it is needed
Team group	An existing Entra ID group with your team. The spoke groups are created with this group as a member, so it must exist before the spoke is created. See Access, groups and PIM.
Address range and subnet plan	The platform team allocates the range from the central IP plan. Say how many addresses and subnets you need and leave room for growth. See IP range and subnets.
Tags	Owner, department, workload, cost centre and whether you process personal data. See Naming and tags.
Approvals your organisation requires	Many organisations require the approval of the product owner and of architecture and security before a workload is created, and a registration in an asset register (CMDB). The platform team can't skip these steps.
Internet exposure	Whether the workload is published to the internet. This decides the management group and whether you need the Application Gateway.
A way to reach private resources	A managed device and a network path (for example VPN) for the people who deploy.

Moving an existing workload

If the workload already runs somewhere else (on-premises, another landing zone or another cloud), follow the phases in Migrate a workload to the platform. The onboarding steps above are the first part of that path.

Operating-model notes

• Managed (XMMS): the approvals in steps 4 and 5 are your organisation's (design authority, security officer). XMMS prepares and implements the spokes.
• Self-managed: your platform team also takes the role of intake and implementer. Whether steps 3 to 5 apply is your organisation's decision.

See Operating models.