Portability + Off-Boarding
Off-boarding NoCode is like moving out of a fully furnished apartment. The landlord hands you the architectural blueprints, the manufacturer details for all the furniture, and the literal keys, so you can build a perfect replica on your own property. Every artifact you receive on day one of migration is also every artifact you walk away with if you decide to leave.
"Hybrid delivery" is a promise until it is tested. Here is why the test passes: each deliverable is an industry-standard format with a portable runtime already in the open-source ecosystem. Glass walls, not a black box.
An open industry-standard spec. Any Linux or macOS host with Docker runs your stack identically to how it ran on NoCode infrastructure. No cloud-vendor abstractions. No proprietary orchestration. Convertible to Kubernetes via off-the-shelf tooling.
An open, inspectable, industry-standard weight file. Runs on llama.cpp, vLLM, Ollama, or any future inference engine that adopts the format. Swap runtimes without touching the weights. Benchmark alternatives without asking permission.
Every deployment exposes OpenAI-schema-compatible endpoints. After off-boarding, your application makes the same API calls it always did. Point the base URL at your own hosted endpoint and the rest of your stack does not care. Zero engineering downtime at cutover.
The exact routing configuration for your deployment in human-readable form. Which workload maps to which model, which thresholds trigger which response tiers. You can read it, edit it, and ship changes without calling us. Frozen and yours on day one of off-boarding.
The procurement-stage objection to any managed service is the "handing the keys and the steering wheel but keeping the engine block in a vault" problem. Here is the engine block.
NoCode migrations deploy on industry-standard formats, open-standard protocols, and documented configuration. If you terminate the managed service for any reason, you receive the artifacts below within 30 days of contract close. Your engineers can run the stack on their own hardware, in their own data center, without contacting NoCode.
Every NoCode deployment is built on these four building blocks. Off-boarding just means handing them over with the managed layer removed.
Standard Docker Compose bundle defining every runtime service in your deployment: inference server, queue proxy, router, monitoring agent. All images are either public registry images or self-contained builds with published Dockerfiles.
Runs on any Linux or macOS host with Docker. Portable to Kubernetes via standard compose-to-k8s conversion (kompose). No cloud-vendor-specific abstractions.
Full model weights in industry-standard GGUF format, unencrypted, with accompanying model cards documenting provenance, license, training-data disclosure status, and quantization parameters.
Runnable by any GGUF-compatible runtime: llama.cpp, vLLM, text-generation-inference, or any future inference engine that adopts the format. You can inspect them, benchmark them against alternatives, and swap them out at will.
Every NoCode deployment exposes OpenAI-schema-compatible API endpoints. Your application code calling NoCode uses the same request and response shapes as if it were calling OpenAI directly.
After off-boarding, your code keeps working with zero integration changes. Point the base URL at your own hosted endpoint and the rest of your stack does not care. No proprietary SDK dependency. No NoCode-specific client library.
The exact routing configuration for your deployment in human-readable YAML. Which workload maps to which model, which thresholds trigger which response tiers, which categories have the overflow valve enabled. You can read it, edit it, and ship changes without calling us.
This is the output of NoCode's proprietary heuristic-mapping engine, as a static configuration. It is not the engine itself. You keep the ruleset forever. The engine that generates new rulesets stays proprietary - but your current ruleset is permanently yours.
Yours, forever: The model weights, the container files, the API endpoints, the frozen routing ruleset. Your deployment runs indefinitely after off-boarding without any NoCode dependency.
Ours, proprietary: The heuristic-mapping engine that generates new routing rulesets. The calibration pipeline that retunes configurations when new models ship. The internal benchmark dataset. The optimization techniques that produce quarter-over-quarter improvements. If you want ongoing improvements to the ruleset after off-boarding, you can re-engage the managed service. If you want to freeze and operate what you have, you can - and it keeps working.
Always-fresh escrow checkpoint
Your escrow bundle is regenerated on a documented daily cadence for every active engagement. The Compose files, model weight catalogs, API endpoint specs, and routing ruleset reflect the production state of your deployment as of the last 24 hours.
Once a week, the most recent bundle is verified on clean staging hardware: cold-boot, cold-deploy, run a smoke test against a copy of your routing ruleset. If the verification fails, an internal incident opens immediately. If you ever pull the off-boarding trigger, you receive the most recent verified bundle - not a 30-day rebuild sprint. The 30-day delivery window is a contractual ceiling, not the actual cadence.
The escrow bundle is post-mortem disaster recovery. This section covers the other half of the question: if NoCode's routing breaks at 3am Sunday, what happens before anyone reaches for the escrow bundle?
Production routing layer is down or returning materially-wrong outputs to customer traffic. NoCode acknowledges within 1 hour, joins the incident bridge, and works to resolution.
Drift alerts, calibration anomalies, configuration questions, anything not actively breaking production. Acknowledged within 4 business hours during the active engagement window.
A documented runbook ships with the engagement. Your on-call engineer can roll back routing, force a workload to its cloud failover path, or drain the queue without NoCode in the loop. The runbook is part of the escrow bundle (regenerated daily) so it never goes stale.
The numbers above are the floor, not the ceiling. Enterprise-tier engagements can negotiate tighter response times (sub-30-minute sev-1, 24/7 on-call rotation) at audit time and have them written into the SLA addendum.
During-engagement MTTR is documented in the SLA addendum signed at the start of the engagement. It is distinct from the post-mortem off-boarding flow above. Both are bundled with every NoCode engagement.
The operational flow if a customer terminates the managed service. Documented. Bounded. Time-limited.
Customer notifies termination (any reason, no penalty clause). NoCode freezes configuration and issues a 30-day delivery clock.
All four artifacts packaged: Compose bundle, model weight files, API endpoint spec, frozen ruleset + manifest. Checksums published. Delivered via encrypted archive of your choice.
Customer team stands up the deployment on their own infrastructure. NoCode available for integration questions during this window. Production traffic remains on managed service.
Customer cuts production traffic to their self-hosted stack. Managed service sunsets on a documented date. Artifacts remain yours forever.
The off-boarding terms are documented in the SLA addendum before you sign anything. Procurement reviews it up front. You never pay for a promise that is not testable.
Start a Free Audit Read the methodology Continuous Calibration + SLA Trust + security Back to the main site