Integration walkthrough
This guide summarises the changes vendors typically make to meet the operating requirements, in the order most teams tackle them, with effort figures from previous onboardings.
How long does it take?
| Application type | Typical effort |
|---|---|
| Cloud-native, containerised or available as code, OIDC-capable | 3–5 days |
| Cloud-native, but proprietary auth | 5–10 days |
| On-premises legacy, not yet containerised | 2–6 weeks |
| Monolith with deep infrastructure dependencies | Architecture review required |
Step by step
1. Choose your runtime
Decide whether your application will run on the platform as a containerised service, as code, or directly deployed onto Kubernetes. The selection of the runtime has implications on how the integration continues. You can also choose a combination of different runtimes, i.e. a different runtime for your frontend and backend services.
1. Create a Landscape for your application
Start working with the platform and incrementally build your deployment configuration (ci.yml).
This includes the selected runtimes and all prepation steps, but also all dependencies such as Managed Services.
Typical effort: 1–2 days if the application already follows twelve-factor principles.
2. Delegate authentication via OIDC
Replace application-own auth with OIDC delegation to the platform's IAM, including claims mapping onto your roles and a logout that ends the session. Often it is enough to configure an OIDC library in your existing framework.
Typical effort: 0.5–1 day with a standard framework; more if auth is deeply home-grown.
3. Externalise configuration and secrets
Move hardcoded configuration to environment variables, values or CRDs (twelve-factor pattern). Secrets shall be injected at runtime as they come from the platform's Secret Management.
Typical effort: 0.5 day.
4. Replace or document external dependencies
Check every external call: can it be replaced with one of the available platform service or does it need to stay? Document all remaining external connections, because each one needs approval.
Typical effort: 0.5 day to audit; replacement work depends on what you find.
5. Run the security checks yourself
The platform tests with image scanning, SAST, DAST and penetration tests. The same checks can be run in your own pipeline beforehand.
6. Prove backup, restore and export
Familiarize with the platform capabilities for backup and restore. Run a restore from a real backup and measure how long it takes; that measurement is your RTO evidence. Then implement a complete data export in open formats (SQL dump, CSV, JSON) with a data model description that allows interpretation without vendor assistance.
Support during onboarding
Throughout technical onboarding, a GovTech engineer is available for technical questions. Coordination runs through the ticket system or agreed sync calls.