How to Move Away from Fluxx Grantmaker (And What to Migrate To)

A practical guide for foundations leaving Fluxx Grantmaker — what migrates, what doesn't, and how to run a parallel transition without disrupting live awards.

By Plinth Team

Leaving Fluxx is more achievable than it feels from the inside. The main barrier is not your data — grant award records, grantee details, and financial histories can all be exported and migrated. The real challenge is the accumulated configuration: Liquid-coded form templates, custom reporting dashboards, assessor workflows, and the institutional knowledge of whoever built and maintains your Fluxx environment. That configuration is not portable in the way data is.

The most practical exit route is a parallel-running approach: run new grant rounds on a replacement platform while Fluxx continues managing live awards until they close naturally. This avoids a hard cut-over, protects active grantee relationships, and gives your team time to build confidence in the new system before Fluxx is wound down entirely.

Why Foundations Want to Leave Fluxx

Fluxx Grantmaker is a capable platform with a large US customer base, and for some large, technically resourced foundations it works well. But a consistent pattern of frustrations has emerged — particularly among UK foundations and smaller teams.

Liquid code dependency. Fluxx uses Liquid, a templating language, for form configuration, email templates, and custom logic. This means that meaningful customisation requires technical knowledge that most grants teams do not have in-house. Changes to forms, workflows, or communications typically require either a developer, a specialist consultant, or a long queue for Fluxx's own implementation team. What should be a quick form update can take weeks or months.

Long change cycles. The combination of Liquid dependency and a complex configuration architecture means that iterating on your programme design is slow. Foundations that want to respond to strategic shifts — new eligibility criteria, a new programme strand, a restructured assessment process — find themselves constrained by what can realistically be changed in the time available.

Limited UK compliance integration. Fluxx was built for the US market. UK-specific requirements — Charity Commission verification, Companies House lookups, OFSI sanctions screening — are not natively integrated. UK foundations typically manage these checks manually or through separate tools, which means compliance documentation is fragmented rather than integrated into the case record.

Implementation overhead. New Fluxx implementations typically take three to six months, require significant internal project resource, and often involve external consultants. The cost — in both time and money — means that the barrier to getting started is high, and the cost of switching is perceived to be similarly high.

Pricing. Fluxx is priced for larger foundations. For mid-size UK foundations managing programmes of £500k–£5m per year, the cost-to-value ratio has become harder to justify as more focused alternatives have emerged.

Why Leaving Feels Hard: What You Have Built in Fluxx

The real switching cost is not the annual licence. It is the configuration you have accumulated over time — and the legitimate anxiety about whether that configuration can be recreated elsewhere.

In a mature Fluxx environment, you typically have:

Custom application and reporting forms built using Liquid code, often iterated over multiple years to reflect the precise language and structure your programmes require. These forms encode institutional knowledge about what you need from applicants.

Email templates — acknowledgement emails, decision letters, monitoring reminders — that may have been carefully crafted and are trusted by your team and grantees.

Assessment workflows — scoring grids, assessor assignments, panel review stages — that reflect how your board or grants committee actually works.

Payment and conditions logic — milestone-triggered payment schedules, conditions precedent, and payment approval workflows that are embedded in the system.

Grantelligence dashboards — Fluxx's reporting and analytics layer, which may have been configured to produce portfolio summaries, geographic analyses, or trustee reports that your board relies on.

Understanding what you have built — and which parts of it are genuinely essential versus historically accumulated — is the first step in a realistic migration plan. The honest answer is that most foundations, when they audit what they actually use day-to-day, find that a significant portion of their Fluxx configuration is rarely touched.

What Migrates and What Does Not

Not everything in Fluxx is portable. The table below summarises what can realistically be transferred to a replacement platform and what will need to be rebuilt.

ComponentMigrates?Notes
Grant award recordsYesExport via Fluxx's reporting; import as structured data
Grantee organisation recordsYesExport contact and organisation data; re-import with field mapping
Payment historiesYesFinancial records can be exported and imported as reference data
Application historiesPartiallyStructured fields migrate; complex Liquid-rendered content may need reformatting
Monitoring report submissionsPartiallyContent can be exported as PDF/data; form structure will not transfer
Custom Liquid form templatesNoLiquid code is Fluxx-specific; forms must be rebuilt in the new platform
Email templatesPartiallyCopy and paste the text content; the sending logic must be rebuilt
Grantelligence dashboardsNoFluxx's analytics layer is proprietary; equivalent reporting must be configured in the new system
Assessment scoring configurationsNoScoring logic must be rebuilt; historical scores can be exported as data
Workflow automation rulesNoWorkflow logic is platform-specific; core workflows must be rebuilt
Attached documentsYes (manual)Documents can be downloaded from Fluxx and re-uploaded; not automatable at scale
Contact/user accountsPartiallyUser data can be exported; accounts must be re-created in the new system

The practical implication: your data is safe. Your configuration is not transferable, but rebuilding it on a modern platform is typically faster than you expect, particularly if the replacement platform's native functionality covers more of your needs without requiring custom code.

The Parallel-Running Approach

The safest way to exit Fluxx is to not exit it all at once. Instead, open your next grant round on the replacement platform while Fluxx continues managing all awards that were made under the old system.

This works as follows:

Immediately: New grant rounds open on the replacement platform. Applications are received, assessed, awarded, and monitored entirely within the new system. Your team begins building familiarity with the new platform on real work.

Concurrently: Live Fluxx awards — grants that have been made, where payment schedules are active and monitoring obligations are running — continue to be managed in Fluxx. Grantees submit monitoring reports through the existing Fluxx portal. Payments continue through existing approval workflows.

Over time: As active Fluxx awards close out, they move to archived status. The Fluxx instance becomes progressively less active. The replacement platform becomes progressively more central to day-to-day work.

At wind-down: Once all active Fluxx awards are closed, export a final archive of all records, terminate the Fluxx contract, and ensure your data is securely stored in either the new platform or an offline archive.

The key discipline during parallel running is to be clear about which system is the master record for each grant. A grant that opened in Fluxx stays in Fluxx until it closes. A grant that opens after the transition date lives in the new system. Do not duplicate records across both systems.

Choosing a Replacement: What Fluxx Users Need to Know

If you are evaluating replacements, the criteria that matter most to teams coming from Fluxx are somewhat different from those evaluating grant management software for the first time.

Configurability without code. The most common pain point in Fluxx is the Liquid dependency. Look for a platform where a grants officer — not a developer — can configure application forms, edit email templates, and adjust assessment workflows. If configuring a new question requires raising a ticket or calling a consultant, you are trading one problem for another.

Time to deploy. A Fluxx implementation that took four months should not be replaced by another four-month implementation. Modern platforms, including Plinth, are designed to be set up in days to weeks rather than months. Test this claim by asking for a specific timeline and by speaking to similar organisations about their experience.

UK compliance built in. If your current Fluxx setup requires manual Charity Commission checks, separate OFSI screening, and manual Companies House lookups, the opportunity to consolidate these into an integrated workflow is significant. Plinth runs these checks automatically and saves the results to the case record as a timestamped audit trail — something Fluxx does not provide natively.

AI-assisted assessment. Fluxx's assessment tools require significant configuration to produce useful reviewer support. Platforms with native AI assistance — summarising applications against your criteria, drafting reviewer notes, flagging missing information — provide this functionality out of the box with less setup. For high-volume rounds, this is a meaningful efficiency gain. See our AI grant management guide for more on what AI assistance in grantmaking looks like in practice.

Analytics that replace Grantelligence. Fluxx's Grantelligence is a genuine strength — it provides portfolio-level analytics and visualisations that many foundations rely on for trustee reporting. Before committing to a replacement, test its reporting and impact capabilities specifically. Plinth generates AI-assisted impact reports that read monitoring submissions and produce portfolio-level summaries, which covers much of what Grantelligence is used for in practice.

Pricing. Compare total cost of ownership, including implementation, configuration, and ongoing support — not just the licence fee. A platform with a lower licence fee but significant implementation costs may not be cheaper overall.

For a broader comparison of Fluxx alternatives, see our guide to the best Fluxx alternatives.

Migration Timeline and Realistic Expectations

PhaseActivitiesTypical Duration
Fluxx auditDocument current configuration: active programmes, form structures, live awards, monitoring schedules, dashboards in use1–2 weeks
Platform selectionEvaluate alternatives, run demos, speak to similar organisations, negotiate terms2–4 weeks
New platform setupConfigure programme structure, rebuild application forms, set up user accounts, configure due diligence integrations1–3 weeks
Parallel launchOpen next grant round on new platform; Fluxx continues managing live awardsOngoing from this point
Data export from FluxxExport grantee records, award histories, and financial data; import active grant records to new system1–2 weeks (can run concurrently with setup)
Team trainingOrient grants officers, assessors, and finance staff to new platform1–2 days per team
Fluxx wind-downFinal export of all Fluxx records; contract termination; offline archive stored securelyWhen last active award closes — typically 12–18 months post-transition

The most common surprise for teams going through this process is how quickly the new platform becomes the operational default. Once a full grant round has been run in the new system — from application intake through to award and first monitoring cycle — the familiarity and confidence shift meaningfully.

The most common challenge is discipline around parallel running. There is a temptation to start entering new information into the new system for grants that were originally set up in Fluxx, or to keep Fluxx as a "backup" even after the transition. Resist this. The parallel-running approach works because the boundary is clean: grants that originated in Fluxx stay in Fluxx until they close.

What Post-Migration Looks Like

After a successful transition, the operational picture is substantially different from a Fluxx environment in several practical ways.

Configuration is owned by the grants team. Form changes, new programme setup, updated email templates — these are tasks a grants officer handles directly, not tickets raised to a developer or consultant.

UK compliance is integrated. Charity Commission status, Companies House filings, and OFSI screening are checked automatically at the point of application and recorded to the case file. Your due diligence trail is complete without additional manual steps. See our due diligence automation guide for details.

Assessment is faster. AI-generated summaries surface key information from each application against your criteria before assessors begin their review. Reviewer notes are drafted automatically and edited rather than written from scratch.

Impact reporting requires less manual effort. Monitoring reports submitted through the grantee portal are read automatically. Outcomes, locations, and key data points are tagged and compiled into portfolio summaries. The quarterly or annual report to trustees is produced from live data rather than assembled manually.

The Fluxx archive is accessible but inactive. Your exported Fluxx data — grant records, historical applications, financial histories — is stored in a format you control, available for reference or audit purposes without requiring an active Fluxx account.

The transition from Fluxx is not painless — rebuilding configuration and managing a parallel-running period requires genuine effort. But for most UK foundations that have been through it, the operational environment on the other side is meaningfully simpler and more responsive to programme needs.

Frequently Asked Questions

Can we export all our data from Fluxx before we leave?

Yes. Fluxx allows data export via its reporting tools, and most data — grant records, grantee details, payment histories, application submissions — can be exported in structured formats (CSV, Excel). Documents attached to case records need to be downloaded manually or in bulk, which takes more effort. It is worth completing a full data export early in the process, both as insurance and to inform your migration planning.

How do we handle grantee communications during the transition?

For grantees with active awards in Fluxx, nothing changes — they continue to interact with Fluxx as they have been. For new applicants and grantees in rounds that open on the new platform, the experience is with the new system from the start. You do not need to explain the internal transition to grantees unless it affects their experience directly.

What happens to our Grantelligence dashboards?

Grantelligence is proprietary to Fluxx and does not migrate. Before leaving Fluxx, export the underlying data that feeds your most-used dashboards — this gives you the raw data to reconstruct equivalent views in a new system. If you rely heavily on specific Grantelligence reports for trustee presentations, document exactly what those reports show so you can recreate equivalent outputs on the new platform.

How do we handle the period when some grants are in Fluxx and some are in the new system?

This is the parallel-running period, and it is operationally manageable as long as you are clear about which system is authoritative for which grants. A simple internal reference document — "grants awarded before [date]: Fluxx; grants awarded from [date]: new system" — is usually sufficient. Most grant programmes have distinct cohorts (spring round, autumn round) that map naturally to a transition boundary.

Will our assessors need significant retraining?

The amount of retraining depends on how configured your current Fluxx assessment workflow is. The core task — reading applications and recording scores and notes — is straightforward in any platform. The specific interface and workflow will be different, which typically requires half a day of structured introduction rather than weeks of training. AI-assisted assessment features, if new to your team, may need a more careful introduction with discussion of how to use and review AI-generated content appropriately.

How should we approach the board conversation about changing systems?

The most effective framing is: we are not migrating everything at once, we are opening the next round in a better system while protecting all active awards. The risk is low because nothing about live grants changes until they close naturally. The case for change is strongest if you can quantify the current overhead — time spent on manual compliance checks, form configuration delays, reporting assembly — and compare it with what the new system handles automatically.

Is there a risk of data loss during migration?

The migration risk is manageable with a structured approach. Export all data from Fluxx before beginning, store it securely, and verify imports into the new system against the source data before going live. The parallel-running approach means you are not dependent on a successful migration to keep the programme running — Fluxx continues operating until you are confident the new system is working correctly.

Recommended Next Pages


Last updated: February 2026