Self-assessment checklist
Work through this checklist to see whether your application can run on the platform, and where adaptation work is waiting. It mirrors the requirement chapters one to one; every "no" links you to the chapter that explains what is expected.
info
This is guidance for your own planning. The binding assessment happens in the platform's admission process, against the contract documents of your procedure.
Five questions that decide the most
Before the tables: the five issues that most often rule an application out, or drive the bulk of the adaptation effort.
- Does it run in one of the four runtime types without code changes? Dependencies on one provider's proprietary services are the most common blocker.
- Can login be delegated to an external OIDC/OAuth2 identity provider? A proprietary, application-own auth system is the most common single piece of rework.
- Can it be installed, upgraded and rolled back with zero manual steps? Steps that require manual host access fail this requirement.
- Can it live without infrastructure admin access? Vendors receive no cluster or host privileges, for installation or for operations.
- Can customers leave with their data? Complete export in open formats, interpretable without your help.
The full checklist:
Runtime & deployment
| # | Requirement | Met? |
|---|---|---|
| 1.1 | Runs in at least one of the four runtime types (Managed Containers, Kubernetes/Cloud Native, Codesphere Reactives, Virtual Machines) without code changes | ☐ |
| 1.2 | No hard dependencies on cloud-provider-specific managed services or proprietary cloud APIs | ☐ |
| 1.3 | Fully described in a declarative Landscape definition; deployment runs from it alone | ☐ |
| 1.4 | Deploy, upgrade and rollback fully automated and repeatable | ☐ |
| 1.5 | No manual intervention on host systems | ☐ |
| 1.6 | Configuration exclusively via parameters, values, CRDs or environment variables | ☐ |
| 1.7 | No secrets in the image or source code; secrets drawn from the platform Vault | ☐ |
| 1.8 | Deployment artefacts versioned in openCode and sourced only from there | ☐ |
| 1.9 | Works under a platform-provided domain with platform-provided certificates; no own domains/certs required | ☐ |
| 1.10 | All external connections documented | ☐ |
| 1.11 | On Kubernetes or VMs: conformity with the platform's Confidential Computing standards | ☐ |
Identity & access
| # | Requirement | Met? |
|---|---|---|
| 2.1 | OIDC/OAuth2 login against an external IdP; no parallel own authentication | ☐ |
| 2.2 | Claims mapping onto application roles works | ☐ |
| 2.3 | Logout actually ends the session | ☐ |
| 2.4 | Role and permission concept documented comprehensibly | ☐ |
→ Identity and access management
Data & backup
| # | Requirement | Met? |
|---|---|---|
| 3.1 | Uses a platform managed database (e.g. PostgreSQL) or deploys and manages its own | ☐ |
| 3.2 | Backup runs regularly, restore works, both are logged | ☐ |
| 3.3 | Database schema migrations run automated and are documented | ☐ |
→ Data storage and persistence
Resilience & scaling
| # | Requirement | Met? |
|---|---|---|
| 4.1 | No single points of failure in critical components | ☐ |
| 4.2 | Survives pod restarts, rolling updates and node failures without data loss or manual intervention | ☐ |
| 4.3 | Stateful components keep consistent state across restart and relocation | ☐ |
| 4.4 | Resource requests, limits, security level and scaling boundaries stated; HPA recommendations available | ☐ |
→ Availability, resilience and scaling
Observability
| # | Requirement | Met? |
|---|---|---|
| 5.1 | Structured logging via the platform's logging service | ☐ |
| 5.2 | No secrets or sensitive data in logs | ☐ |
| 5.3 | Working, documented liveness/readiness health checks | ☐ |
| 5.4 | Runbooks for operations and incident handling exist and are current | ☐ |
| 5.5 | (Should) Prometheus-compatible metrics, SLIs, OpenTelemetry tracing | ☐ |
→ Observability and supportability
Security & data protection
| # | Requirement | Met? |
|---|---|---|
| 6.1 | Would pass image scanning, SAST and DAST today; no open critical/high findings | ☐ |
| 6.2 | Patch process can meet the profile deadlines (critical ≤ 15 days Standard / ≤ 7 days KRITIS) | ☐ |
| 6.3 | Uses platform TLS termination; no own certificates, trust stores or unencrypted endpoints | ☐ |
| 6.4 | If personal data is processed: AVV can be concluded, sub-processors disclosed with flow-down | ☐ |
| 6.5 | Security incident reporting path to the platform defined | ☐ |
→ Security, compliance & data protection
Service levels & support
| # | Requirement | Met? |
|---|---|---|
| 7.1 | Your organisation can carry the target SLA profile (availability, response times, support coverage) | ☐ |
| 7.2 | Architecture, backup and failover design sustain the RTO/RPO corridor of your profile | ☐ |
| 7.3 | Escalation roles (team lead, management) named and reachable | ☐ |
| 7.4 | Monthly service report (availability, incidents, MTTR, releases, security findings) producible | ☐ |
| 7.5 | Change process with risk analysis, rollback plan and test evidence established | ☐ |
→ Service levels & support · ITSM processes
Documentation & exit
| # | Requirement | Met? |
|---|---|---|
| 8.1 | The six operating documents exist and are current (connections, roles, health checks, runbooks, migration/exit, backup/restore) | ☐ |
| 8.2 | Release notes and a vulnerability analysis ship with every release | ☐ |
| 8.3 | Complete data export in open formats (SQL dump, CSV, JSON) works | ☐ |
| 8.4 | Data model documented well enough to interpret the export without vendor assistance | ☐ |
| 8.5 | Deletion/handover with evidence, including backups, is feasible | ☐ |
| 8.6 | Transition support capacity can be planned and priced | ☐ |
→ Documentation & evidence · Exit & portability
What next?
If most answers are yes, the onboarding journey shows the concrete path to production. For areas with several noes, the integration walkthrough gives typical effort figures for the adaptations.