Flowise published a shutdown notice on July 29. The repository freezes immediately, moves to public archive status on August 10, and reaches official end of life on August 31. That sounds like a month to migrate. It is less than a month to preserve the parts of your system that a migration tool will never understand.

Flowise and Agent Builder migration deadlines

The timing is awkward because Flowise is not an obscure experiment. Its GitHub repository shows 55.2k stars and 24.8k forks, and the project still documents a normal self-hosted install. The official sunset notice says the code remains available under Apache 2.0 and invites users to fork it. That is technically true. It is also an easy way to underestimate the work you are accepting.

The useful question is not "which Flowise alternative is best?" It is "which part of my workflow am I willing to own?"

Export the Workflow Before August 10

Do this before comparing products. Open every production flow and create a migration bundle that another engineer could run six months from now without your memory.

Save the visible graph. Export every flow JSON and record its public endpoint, trigger, input schema, output schema, and the version that is currently serving traffic. Take screenshots of the canvas only as a reference. Screenshots are not backups.

Save the invisible dependencies. Put prompts, system instructions, model names, temperature settings, tool schemas, custom code, parsers, vector-store settings, webhook contracts, and retry behavior in a text directory. Copy the dependency lockfile and the exact container or npm version. Flowise's own setup docs list Node v18.15.0 or v20 and above as supported, while its current repository README points self-hosted users to Node.js 20.0.0 or newer. Write down the version you actually run, not the version the latest documentation happens to mention.

Treat credentials as a separate migration. Never throw API keys into a flow export or a Git repository. Record the credential name, provider, scopes, rotation owner, and the environment variable or secret-store key that supplies it. If a flow reads from S3, Postgres, a private API, or a local file, document the network path and the permission boundary. A JSON file can preserve a node while silently losing the thing that made the node work.

Capture behavior, not just configuration. Keep ten representative inputs and expected outputs. Include one empty input, one malformed input, one timeout, and one permission failure. Run them against the live flow and save the responses. You need a regression set before you change builders, prompts, or model providers. Otherwise a successful import only proves that a canvas loaded.

The repository archive date is August 10, 2026. After that date, the source remains available. Issues and pull requests lock, and the npm packages and Docker images are marked deprecated. You still possess the code, but the public maintenance loop has stopped.

Pick a Replacement by Boundary

A fork is reasonable when your workflow is already a product, your team can maintain a TypeScript monorepo, and you need Flowise's exact node behavior. The Apache 2.0 license helps with that path. It does not provide security patches, compatible dependency upgrades, or someone else to absorb model API churn. Fork only if a named person owns those jobs and you have a budget for them. "We can maintain it" is not an operating plan.

Langflow is the more natural destination when the core asset is an AI flow that developers still need to inspect and tune. Its documentation supports flow JSON, Docker packaging, API execution, and custom Python components. That gives you a path to keep a visual editor while moving the runtime into a deployment you control. The catch is translation. A Flowise graph is not a Langflow graph. Rebuild each component, then compare the saved regression inputs rather than trusting a visual resemblance.

n8n makes more sense when the AI step is one action inside a larger business process. Email, CRM, ticketing, approvals, schedules, and HTTP calls are its center of gravity. n8n's documentation provides CLI exports for all published workflows and separate credential exports. It also warns that exported workflow JSON can include credential names and that HTTP Request nodes may contain authentication headers copied from cURL. Scrub exports before sharing them. Migration convenience is not a security control.

Code is the correct destination when reliability depends on deterministic branching, tests, typed interfaces, or a stable deployment contract. You lose the friendly canvas and gain ordinary software tools: version control, code review, unit tests, dependency pinning, and an owner who can be paged. That trade is usually worth it once a workflow controls money, customer data, or an irreversible write action.

OpenAI's Agent Builder shutdown makes the same point in a different ecosystem. OpenAI says Agent Builder will shut down on November 30, 2026, while ChatKit remains available. Its migration guide tells users to open the workflow, choose Code, select Agents SDK, and export TypeScript or Python. It also says some behavior needs manual recreation, especially control flow, triggers, tools, authentication, and permissions. That is not a Flowise migration utility, but it is a useful warning about visual abstractions: the graph is portable; the surrounding service contract rarely is.

For a small internal prototype, choose the maintained tool that matches the boundary and rebuild it. For a public workflow with real users, run old and new versions side by side. Feed the same regression inputs into both, compare outputs and error behavior, then switch traffic gradually. Keep the old deployment frozen until you can restore the new one from a clean checkout.

The self-hosting break-even problem matters here too. A fork can look free because the license costs nothing. The bill arrives as patching, monitoring, backups, incident response, and time spent relearning an abandoned codebase.

The Part Worth Keeping

Flowise's explanation is blunt: coding agents are eating into the developer side of rigid low-code workflows. That is probably true, but it misses the users who chose a canvas because they were not supposed to become maintainers of a large JavaScript application. Telling those users to fork is not a migration plan.

The practical lesson is narrower. Keep your workflow definition, prompts, test cases, and secret inventory in formats that do not depend on one editor. Treat the visual builder as a view over those assets, not as the only place they exist. When the next builder announces a sunset, you should be moving a tested contract, not taking screenshots of a graph.

Try this tonight: export one production flow, rotate any credential that appears in a shared file, and run the regression inputs against a blank replacement project. The first failed import will tell you more than another comparison article.

Sources