You can start adopting Forte with application hosting. Deploy an existing HTTP backend as a Service, validate its generated endpoint, and use Forte's deployment history, health checks, and request diagnostics while evaluating the move. Compatible existing databases, authentication, and payments can remain in place for this first stage.
That gives the team a concrete first benefit: a managed release and operating workflow before a wider platform migration. Move data, identity, and payments as separate decisions when they improve the product's operating model. The achievable interruption still depends on state, long-lived connections, external events, and DNS behavior.
Map dependencies before creating resources
List the frontend, APIs, workers, databases, caches, storage, queues, identity, payments, email/SMS, domains, certificates, outbound allowlists, scheduled jobs, and monitoring. For each dependency, record configuration, data ownership, write behavior, and cutover owner.
Classify dependencies as portable, replaceable, or migration-critical. A standard container may move with few changes. A database with constant writes or an identity system with active sessions needs an explicit transition design.
Move the runtime without changing product behavior
Deploy the existing code to Forte and begin with its current authentication behavior. Service authentication exclusions can leave existing application auth in place while the runtime is validated. Adopt Forte identity or payments later as separate migrations when those changes are valuable.
Configure runtime variables and secrets, expose the required HTTP health route, and test the generated HTTPS endpoint. Compare status codes, latency, headers, background activity, outbound access, and application logs with production.
Decide who owns writes
For a stateless API using the existing remote database, parallel runtime validation may be straightforward. For a database move, select a method based on the engine, size, write rate, and tolerated recovery window.
At every stage, name one authoritative writer. If both old and new stacks accept independent writes without replication or reconciliation, a DNS reversal cannot repair the divergence. Apply the same rule to payment events, scheduled jobs, emails, and queue consumers: prevent duplicate side effects before sending production traffic to both stacks.
Establish cutover criteria
Use a written decision table:
| Signal | Proceed | Abort or pause | Owner |
|---|---|---|---|
| Health checks | Stable over agreed observation window | Candidate restarts or fails checks | |
| Error rate | Matches expected baseline | Material unexplained increase | |
| Critical flows | Sign-in, core write, and billing test pass | Any critical flow fails | |
| Data | Expected records and writes reconcile | Missing, stale, or conflicting writes | |
| Diagnostics | Team can find a deliberate failure | Requests or logs cannot be traced |
Use thresholds appropriate to the product rather than copying arbitrary percentages. Confirm who can change DNS or routing, who can stop new writes, and who makes the final decision.
Move traffic in a reversible step
Lower DNS TTL in advance where appropriate, while recognizing that resolvers and clients may cache beyond the intended period. Add and validate the custom domain and certificate before changing the production record.
If the architecture supports weighted or proxy-controlled routing, start with limited traffic. Otherwise, choose a low-risk window and keep the old runtime ready. Watch customer-facing behavior and dependency state, not only container health.
Define rollback beyond DNS
Rollback needs answers for code, data, sessions, events, and customer communication. A compatible schema and single write authority make runtime reversal easier. An irreversible migration needs a roll-forward recovery plan instead of a nominal rollback button.
Keep the source platform until the observation period, reconciliation, backup, and recovery checks are complete. Then remove old credentials and resources in an ordered inventory so a forgotten callback, domain, or job does not survive indefinitely.
Migrate platform features separately
Once the runtime is stable, evaluate Forte authentication, payments, databases, or Actions one boundary at a time. Each has its own state model and maturity. Forte managed databases and Actions are currently Open Beta; include that in production planning.
Use the Forte migration guide for the initial runtime flow, and plan a supported migration when identity, data, or traffic requires coordinated work.