How to migrate from an archived Flowise to an open-source AI Operating System

What changed at Flowise

Flowise has been archived. Its README now opens with the line "Flowise has been archived", and the project's own sunset notice says the team decided to wind down operations and give people time to fork the code. The timeline is public: active feature development stopped on July 29, 2026, the GitHub repository moved to public archive status in August 2026, and the core team's official presence in Discord and GitHub ended on August 31, 2026. The published npm package and the Docker images are marked deprecated. (Flowise README, the sunset notice)

What an archived tool means for the flows you built

An archived tool keeps running. If Flowise is on your own server today, it will keep answering requests tomorrow, because nothing was switched off inside your copy. What stops is the maintenance around it. No one is reviewing pull requests, no security fixes are landing upstream, and the published package and images are flagged deprecated, so a future dependency or runtime problem is yours to patch. That is the real cost of staying: you inherit every future issue with no upstream to fix it. (the sunset notice)

Flowise is a visual builder. You dragged nodes onto a canvas to assemble chatflows and agentflows, wired them to models, data sources, and tools, and shipped the result through an API, a widget, or the cloud. A flow is a fixed graph: the steps run in the order you drew them. Kortix takes a different shape. Kortix is the open-source AI Operating System, and instead of a canvas of fixed steps you run agents that work on their own cloud computers and hand back finished work, with the configuration in a git repo you own.

The migration, step by step

1. Inventory the flows. Open your Flowise workspace and list every chatflow and agentflow that people still use. For each one, write down three things in plain language: the job it does, the data it reads, and the tools it calls. Most of what looks like a hundred flows turns out to be a dozen jobs.
2. Reproduce each job as an agent. An agent is agents/<name>.md (behavior) plus an agents.<name> block in kortix.yaml (governance). One job becomes one agent, and the prompt you already wrote inside a Flowise node is the first draft of the agent's instructions.
3. Move the connectors. Flowise wired your flows to a queue of apps and data sources. Kortix reaches 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. Connector credentials are brokered server-side and never enter the machine. Reproduce one connection at a time and test it against the agent that needs it.
4. Review the work through change requests. Session work reaches main through a change request. Merge is default-deny for agents. An agent can edit its own configuration on its session branch and propose the change. A person approves it. You keep the review habit your team already has for code, and the platform handles the branch, the diff, and the merge.
5. Run it where you want. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Any model provider with your own keys. Or the ChatGPT plan you already pay for. Open source. Read it, fork it, audit it.

What to leave behind

Three things do not survive the move, and trying to keep them costs more than dropping them.

• The canvas itself. A Flowise flow is a graph you drew on a screen. There is no importer that turns it into Kortix agents, and a node-for-node mapping would carry over the rigid shape you are trying to leave. Treat each flow as a recipe for a job, not a file to port.
• The Flowise-only integrations. A tool that existed only as a Flowise node has no Kortix equivalent until someone rebuilds it. The connector catalog covers the common ones, so check it before you rebuild anything by hand.
• The old runtime. Keep your Flowise instance running only until its last live job has a working agent, then switch it off. An archived instance holding a live API key is a liability you no longer need.