Lucidworks Fusion V1 Connectors Are Removed in Fusion 6

If you run Lucidworks Fusion, there is a piece of work in your future that has not been on many roadmaps: every V1 connector in your deployment has to be replaced before you can upgrade to Fusion 6. This is not a rumor or a reading of the tea leaves. Lucidworks says it plainly in the connector documentation, and the deprecation applies to the whole V1 generation rather than to a handful of stragglers.

The reason it deserves attention now, rather than when Fusion 6 ships, is that connector migration is not a version bump. A connector is the thing that decides what is in your index. Swapping one changes how content is fetched, how it is identified, and often how permissions come across, and that means re-crawling and re-verifying rather than flipping a switch. Teams that leave it until the upgrade window discover the work in the worst possible week.

Are Lucidworks Fusion V1 connectors deprecated?

Yes, all of them. The Fusion Connectors deprecations page states that all V1 connectors are deprecated in Fusion 5.18.0 and later, which means they are no longer being actively developed. Deprecated is not the same as broken: if you are on 5.18.0 today, your V1 connectors still run. What you have lost is forward motion. Bugs in a deprecated connector are unlikely to be fixed, and new capability lands in the V2 and Pro generation instead.

Fusion 5.18.0 became generally available on July 7, 2026, so this is a live constraint for anyone on a current release rather than a distant one. Sites on the 5.9.x long-term support line are in the same position, just with more runway.

Which Fusion version removes V1 connectors?

Fusion 6. The documentation's wording is that V1 connectors "will be removed in Fusion 6", and that customers using one "must migrate to the replacement connector or a supported alternative before upgrading". Lucidworks has not published a public Fusion 6 general availability date, so the honest planning position is that the deadline is real but the calendar is not yet fixed. Treat it as work to schedule in the next planning cycle, not as an emergency.

The practical sequence is straightforward. Inventory which datasources in your Fusion deployment use a V1 connector, check each one against the replacement list, migrate and re-crawl in a lower environment first, then compare result sets before you cut over in production. The comparison step is the one people skip and the one that catches problems, because a replacement connector rarely produces a byte-identical index.

Which V1 connectors have a replacement?

Seventeen have a named replacement in Lucidworks' documentation. The pattern is worth reading, because it tells you how much work each migration actually is.

Two rows in that table are bigger jobs than the others. The SharePoint one is the largest migration most Fusion customers will face, because SharePoint is usually the biggest and most permission-sensitive source in the index, and because four separate connector configurations have to converge on one. Permission mapping is where SharePoint migrations go wrong, so plan to verify security trimming explicitly with test accounts rather than assuming it carried over.

The Alfresco and GitHub rows are different in kind. Their replacements are described as REST recipes rather than drop-in connectors, which means configuration work against an API rather than selecting a new connector from a list. Budget accordingly.

What if my V1 connector has no replacement yet?

Some do not have one. Lucidworks' documentation says that for V1 connectors without a listed replacement, a replacement "is still under development" and the documentation will be updated when it becomes available. That is an honest position from the vendor, and an uncomfortable one for a buyer, because it means part of your migration plan depends on software that does not exist yet.

If you are in that position, the useful move is to ask Lucidworks for a written timeline for your specific connectors before you commit to a Fusion 6 upgrade date, and to identify a supported alternative path in parallel. The documentation explicitly allows "a supported alternative", which in practice can mean pushing content in through the Fusion index API from your own pipeline instead of waiting for a connector. That is more code to own, so treat it as a fallback rather than a plan.

Do I have to re-crawl everything after migrating a connector?

In almost every case, yes. A replacement connector generally produces different document IDs and often a different field structure, so pointing it at the same source produces a parallel set of documents rather than an update to the existing ones. The safe pattern is to build a new collection or datasource with the replacement connector, crawl it fully, compare it against the old one, then switch the query side over and retire the old datasource.

That full crawl matters for two reasons beyond correctness. It takes real time on a large corpus, so it needs a window. And if your Fusion contract is priced by records indexed, which is how Lucidworks licenses the platform, running two indexes side by side during a migration can temporarily push you toward your record ceiling. Check the overage terms in your agreement before you start, because the standard license carries a minimum overage surcharge of 25 percent.

How do we know if a migrated connector quietly stops working?

This is the failure mode that costs the most and gets planned for the least. A connector rarely fails loudly. It fails by fetching less than it used to, and the symptom is a user saying "search used to find this," weeks later, by which point nobody connects the complaint to the migration. Fusion exposes job history and document counts per datasource, and the single most useful habit after a connector migration is to alert on the document count for each datasource rather than eyeballing it.

Treat the connector's source endpoint the same way you treat any other production dependency: something that should page you when it goes quiet, not something you check when a ticket arrives. Teams that already run uptime monitoring on their internal APIs usually just extend it to the systems Fusion crawls, which is a cheaper fix than discovering a stale index a month late.

Should we migrate the connectors or reconsider the platform?

This is the honest question underneath the technical one, and it deserves a straight answer rather than a sales pitch. If Fusion is powering search inside a product you sell, a commerce catalog or a customer-facing experience, migrate the connectors. You bought Fusion for the control it gives you over relevance, that control is still there, and no cross-app search product replaces it. The migration is annoying, not strategic.

If Fusion is powering internal employee search, the calculation is different, because a forced migration is a rare moment when the switching cost of staying and the switching cost of leaving are roughly equal. You are re-crawling everything and re-verifying permissions either way. That is the point at which it is worth asking whether you still want to operate Solr, Spark, ZooKeeper and Kubernetes to answer questions like "what is our parental leave policy in California."

Fusion's connector coverage is also a factor in that specific job. It ships roughly 54 connectors weighted toward enterprise content systems, and Notion, Gmail and Microsoft Teams are not among them, which is a real gap when a large share of internal answers live in exactly those places. Our Coveo vs Lucidworks comparison lays out where each platform genuinely wins, and the Lucidworks alternatives page covers the internal-search case in more detail.

What does this mean if we only use Fusion for internal search?

It means you are about to pay platform maintenance costs for a product-grade capability you are not using. Fusion is a strong platform for teams that own search as a discipline. Connector deprecation cycles, cluster operations, relevance tuning and records-indexed licensing are all reasonable prices when search is part of what you sell to customers. They are hard to justify when the requirement is that an employee asks a question in plain language and gets a trustworthy answer back.

For that requirement, the shape of the tool is different. You want connectors that are somebody else's problem, item-level permissions enforced per person at query time rather than at sync time, and an answer with citations instead of a ranked list you still have to read. That is what InSearch does across Drive, Slack, Notion, Confluence, Gmail, Jira and Salesforce, and there is no index for your team to operate. If you want to see how the whole category lines up first, the enterprise search tools comparison covers sixteen products on coverage, citations and whether the vendor publishes a price at all.

The short version

All V1 Fusion connectors are deprecated as of 5.18.0 and will be removed in Fusion 6. Seventeen have named replacements, the SharePoint consolidation is the biggest of them, some connectors have no replacement yet, and every migration means a full re-crawl and a permissions re-verification. Inventory your V1 datasources this quarter, get a written timeline from Lucidworks for anything without a replacement, and use the forced re-crawl as the natural moment to ask whether the platform still fits the job you are using it for.