How to move from serverless functions to a long-running server

Functions are excellent at what they're for: short, stateless, request-scoped work with variable traffic. The migrations happen when an app grows a part that isn't that — and the tell is usually one of four symptoms, each of which points at the same conclusion from a different direction.

This is how to do that move without turning it into a rewrite. I build PandaStack, so the deploy commands are mine; the approach works on any platform that runs a process.

The four symptoms

• Timeouts. A job, report, or import that keeps hitting the maximum duration, and each fix buys you a few more months before it hits it again.
• Cold starts on user-facing paths. A dependency tree that takes seconds to import, on a request that matters.
• Database connection exhaustion. Every concurrent invocation opens its own connection, and a traffic spike empties the connection limit — a database outage caused entirely by architecture.
• Work you keep faking. A queue consumer implemented as a function that polls on a schedule. A WebSocket you route through a third-party service. An in-memory cache that never hits because every invocation is cold.

If you recognise two or more of these, the workload wants a process. That's not a failure of judgement — it's a workload that changed shape.

Step 1: move the smallest thing that fixes it

The instinct is to migrate the whole app. Resist it. Most function-based apps have one or two handlers causing all the pain and a dozen that are perfectly happy — thin CRUD endpoints, webhook receivers, scheduled cleanups. Those are cheap, scale automatically, and cost you nothing to leave alone.

Sort your functions into two lists: those where an invocation is genuinely a complete unit of work, and those where you've been working around the absence of a process. Move only the second list.

Step 2: unpick the framework wrapper

Handlers written against a provider's signature need a thin adaptation. This is usually less work than expected, because the business logic rarely touches the event object beyond parsing it.

// Before: a provider-shaped handler
export async function handler(event) {
  const body = JSON.parse(event.body ?? "{}");
  const result = await processOrder(body);
  return { statusCode: 200, body: JSON.stringify(result) };
}

// After: the same logic behind an ordinary route.
// processOrder didn't change — only the shell around it.
app.post("/orders", async (req, res) => {
  const result = await processOrder(req.body);
  res.json(result);
});

If your handlers are thick with provider-specific plumbing, extract the logic into plain functions first, as a separate change, while still on the old platform. Doing the extraction and the migration at once means you can't tell which one broke something.

Step 3: things you can suddenly do (and should)

• One shared connection pool instead of a connection per invocation. This alone often removes the reason you migrated.
• In-memory caching that actually hits, because the process lives between requests.
• Expensive setup — a model load, a config fetch, a compiled template cache — done once at startup rather than on every cold start.
• Background work in the same process: a queue consumer, a periodic reconciliation, a metrics flush.
• Long-lived connections: WebSockets, server-sent events, a subscription to Postgres change notifications.

Step 4: things you're now responsible for

This is the honest half. Functions were handling several things silently, and you're taking them back.

1. Scaling. The platform auto-scaled per invocation; now you decide instance counts and thresholds. Start with more headroom than you think and tune down.
2. Memory leaks. In a function, a leak is cleaned up when the invocation ends. In a process that runs for weeks, it grows until the OOM killer arrives. Watch resident memory over days, not minutes.
3. Graceful shutdown. Deploys send SIGTERM; without a handler, in-flight requests are cut.
4. Concurrency bugs. Module-level state was per-invocation and is now shared across every concurrent request. This is the class of bug most likely to surprise you — a cached user object at module scope is a data leak between requests.
5. Restarts. Nothing restarts the process for you between requests any more, which is exactly what you wanted and also means state accumulates.

Step 5: deploy and cut over

# Deploy the extracted service as a long-lived process
pandastack apps create --name orders-worker \
  --git-url https://github.com/acme/orders \
  --build-cmd 'npm ci && npm run build' \
  --start-cmd 'node dist/server.js'

# Route the affected paths to it from your existing edge function
# or API gateway; leave every other function exactly where it is

Cut over one route at a time, behind whatever routing layer you already have. Run both in parallel for the first week and compare error rates. Because you moved a subset, a rollback is a routing change rather than a redeployment of everything.

The short version

Identify which functions were fighting the model, move only those, extract business logic from handler plumbing as a separate step, and take the wins — shared pools, real caching, one-time startup cost. Then accept the new responsibilities honestly: scaling, memory over time, shutdown handling, and shared state. That last one is where the real bugs live, and it's worth an explicit audit before you send production traffic.