On 15 July 2024, Microsoft announced that Fundraising & Engagement, the donor and fundraising solution in Microsoft Cloud for Nonprofit, will be retired on 31 December 2026. Since the announcement Microsoft has delivered no product enhancements; critical security issues are addressed until 31 December 2026. What the retirement means and which paths exist going forward, we covered in the article on the shutdown.
This article takes on the questions most organisations on the solution are sitting with now, in October 2026: what the transition costs, how long it takes, what can realistically be done before the deadline, and how to handle year-end when gift information must be reported to the Norwegian Tax Administration in January.
The short answer: a migration from Fundraising & Engagement to another solution on Dynamics 365 and Dataverse should, as a planning assumption, be given three to six months for a mid-sized organisation, and six to nine months where data volumes or integrations are complex. If you have not started by now, in October, most organisations will not complete a responsible switch before the deadline. Our advice is not to squeeze it into giving season, but to use the autumn for mapping and choosing a path, deliver the 2026 gift reporting from your current solution by the Norwegian Tax Administration's deadline of 20 January 2027 if you are in the deduction scheme, and plan go-live in the first half of 2027 with measures that keep risk down during the unsupported period. The cost is driven more by data quality, integrations and reports than by licences, and because the core data already lives in Dataverse, for most organisations the move is largely a schema migration inside your own environment.
How long does a migration from Fundraising & Engagement take?
The vendor StratusLive, which sells its own replacement solution, estimates in its migration guide (last updated August 2026) that a well-planned migration typically takes three to six months, depending on size and complexity. Where data volumes are large or integrations complex, we plan with six to nine months ourselves, as an experience-based planning assumption. The ranges match what we see in comparable Dataverse projects in the Norwegian market: the calendar time is rarely determined by the technology, but by how quickly decisions are made and how much time your own people can set aside.
A well-run migration follows a recognisable rhythm. The phases overlap somewhat in practice, but the sequence holds:
| Phase | Typical duration | What happens |
|---|---|---|
| Discovery and assessment | 2 to 3 weeks | Document what is actually in use: fields, workflows, integrations, reports, data volumes and data quality. |
| Solution design | 3 to 4 weeks | Map fields and entities to the new solution, design integrations and decide which reports to recreate. |
| Data migration | 3 to 5 weeks | Cleanse, test-migrate a subset, validate donor histories, then run the full migration with checkpoints. |
| Testing and training | 3 to 4 weeks | User acceptance testing, side-by-side validation against the old solution, role-based training. |
| Go-live and follow-up | 2 weeks + | Transition to production, decommission the old application layer, monitor adoption the first weeks. |
Add the weeks up and you land on three to four months of effective project time for an orderly environment. The reason we still plan with three to six months is everything around the project: procurement, decision points, holiday periods and the capacity of your own staff. Plan with slack, not with the optimistic sum.
Running Fundraising & Engagement today? We map your environment, data and integrations and give you a concrete cost and timeline estimate, so the plan for 2027 is ready when January comes.
What does the transition cost? The drivers that actually move the number
Licences rarely decide the total. Two organisations with the same user count can end up with very different project sizes, and the difference sits in five drivers. This is the same cost logic we describe in the article on what a Dynamics 365 implementation actually costs, applied to a narrower project.
Data quality and donor history. Duplicates, incomplete records and many years of giving history are the most common reason the data migration phase grows. The upside is real: a migration includes a cleansing step, so you come out the other side with better data than you went in with.
Integrations. Accounting, payment solutions, donation pages on the website, email platforms. Each connected system must be re-pointed, tested or rebuilt. This is usually the second-largest item, and the one with the widest span between organisations.
Reports and analytics. Reports built on the old data model must be recreated. Many organisations use the occasion to move reporting to Power BI and get more out of it than they had, but the hours belong in the estimate.
Customisations and workflows. Custom fields, automations and adjustments made over the years must be mapped: which ones are actually used, and which ones were configured once and forgotten. In our experience a surprising share falls in the second category, and mapping this honestly shrinks the project.
Training and adoption. The line item that is easiest to cut and most expensive to skip. Fundraisers, finance staff and administrators need different training, and the first weeks after go-live decide whether the new solution gets used.
| Profile | Assumptions | Planning assumption, consulting effort |
|---|---|---|
| Simple | Orderly data, few customisations, one finance integration, standard reports | Roughly 4 to 8 consultant weeks |
| Typical | Several years of history, two or three integrations, a report portfolio to recreate | Roughly 8 to 16 consultant weeks |
| Complex | Payment components, extensive customisation, many integrations and reports | 16 consultant weeks or more |
The consultant weeks show total partner effort, not calendar time. One consultant week equals 37.5 hours and includes project management, training and follow-up right after go-live. Your own internal work, licences, third-party costs and any VAT come in addition, and several consultant weeks can be delivered in parallel.
What does this add up to in kroner? An honest answer requires a mapping of your environment, and we would be sceptical of anyone who quotes a fixed price without one. The ranges in the table are planning assumptions based on comparable Dataverse projects, not a quotation; multiply by your partner's hourly rate for a rough budget indication. The assessment phase exists precisely to replace the assumptions with a number you can budget on.
Schema migration, not platform migration: the advantage of staying on Dataverse
The single biggest cost damper in this transition is architectural. Microsoft is retiring the Fundraising & Engagement solution, not the platform underneath. The core data normally lives in Dataverse, which continues, while some deployments also use Azure services and Azure SQL for parts of the processing. If you move to another solution built on Dynamics 365, the core of the migration is a remapping of your data to a new schema inside your own environment, and no new platform must be procured. The platform integrations with Outlook, Teams and Power BI remain available, but your own reports, field mappings and automations must be tested against the new model and may require rebuilding.
One nuance belongs in the honest version: Fundraising & Engagement is more than a set of Dataverse tables. Depending on how it was deployed, the solution can also include Azure components, among them payment processing, where some data lives alongside Dataverse. The mapping should therefore inventory not just tables and fields, but Azure components, payment integrations, Power Automate flows, plugins and reports. For some organisations the project really is mostly schema remapping; for others it is a broader application replacement inside the same Microsoft ecosystem.
Compare that with moving off Microsoft entirely. Then every record must be exported to a different database architecture, every connected system re-integrated, every user retrained on a new interface, and new licences come on top. It can still be the right choice for an organisation already planning a broader technology shift, but it is a substantially larger project, and it should be chosen deliberately, not as a reflex to a deadline.
Staying on the platform still leaves a real choice between two main directions: a configured or partner-built solution on Dynamics 365 and Power Platform, or a model designed around your own organisation. Within the first direction, Microsoft's Fundraising template app is a flexible, extensible foundation a partner can build on, not in itself a complete replacement for Fundraising & Engagement; settle the functional scope, support responsibility and who will own and maintain the data model. That decision has its own trade-offs around data model ownership, integration freedom and roadmap control, and we have covered it thoroughly in the article on ready-made solution versus your own platform. For organisations that are also rethinking the member or donor foundation itself, the article on membership systems versus a CRM platform frames that bigger question.
"The real deadline was never 31 December. It was the day giving season started. For an organisation that has not switched yet, the right time for go-live is after the 2026 gift reporting and annual statements have been sent, not before New Year."
Cartagena, based on Dynamics 365 and Dataverse deliveries for Norwegian organisations
The timeline from October: what should happen when
As of 12 October 2026, under three months remain to the deadline. A full switch before New Year is therefore unrealistic for most organisations that are not already well under way, and forcing one through would collide with both giving season and gift reporting. StratusLive, too, describes October to December as the worst time for a system migration. The time until January is not lost, though. It should simply be spent on other tasks than the switch itself.
| Period | What happens | Why then |
|---|---|---|
| October | Choice of path and mapping: what is actually in use, which Azure and payment components exist, and which reports must be recreated | The mapping asks little of fundraisers and can run alongside the campaigns |
| November to December | Change freeze on everything that touches fundraising. Solution design and test migration in a separate environment | No changes in production while the gifts come in |
| 1 to 20 January 2027 | The 2026 gift information is sent to the Norwegian Tax Administration from the current solution or a controlled extract from it | The deadline is 20 January, and no extension is granted |
| February to June 2027 | Full migration, acceptance testing, training and go-live | After donors have received their annual statements, which must be sent by 15 February |
The sequence is deliberate. Organisations approved for the deduction scheme for gifts must report the total gift amount per donor to the Norwegian Tax Administration. The reporting draws on the full year's donor history, and a system change in the middle of that period is an unnecessary risk. Let 2026 close in the system where the gifts were recorded, and let 2027 start in the new one.
One more practical point: the Norwegian Tax Administration is removing the old Altinn roles for submitting gift information in January 2027, and from then on the correct access package is required. Check well in advance that whoever submits the reporting has that access in place.
Pattern: around technology deadlines we often see two courses. An organisation that realises in October it will not make the switch spends the autumn on mapping and test migration, delivers the gift reporting from the old solution in January and goes live on the new one in the spring. An organisation of the same size tries to make New Year, switches in the middle of the December campaign and spends January correcting donor records before the reporting deadline. The first plan looked slower on paper and was safer in practice.
The unsupported period: how to keep the risk down
Microsoft's announcement describes the end of support and of handling critical security issues after 31 December 2026, not that the solution is switched off on 1 January 2027. For an organisation that manages donor data, national identity numbers and payment information, that is a risk that grows over time. The goal is therefore not to pretend the period does not exist, but to make it short, bounded and documented.
| Measure | What it means in practice |
|---|---|
| Stop new dependencies | No new flows, fields, integrations or reports against Fundraising & Engagement from now on. |
| Map the Azure components | Find out which Azure resources, payment integrations and background services the deployment uses, who owns the subscription, and what should happen to them after the end date. |
| Tighten access | Review who has access to donor and payment data, and remove access that is no longer needed. |
| Take a controlled extract | Test the extract before Christmas, and take the final extract of the 2026 donor history right after year-end, so gift reporting does not depend on the solution behaving as before. |
| Set an end date | Decide the go-live date on the new solution and when Fundraising & Engagement is decommissioned, and document the assessment for the board and the auditor. |
The last point matters most. The difference between a controlled transition period and simply staying put is that the period has an end date the board has approved, and a partner who knows the solution. Running without support and without a plan is the outcome to avoid.
Can a migration assessment be funded through a partner?
For qualifying organisations, Microsoft funding for a migration assessment may be available through a partner description of the scheme; availability and scope must be confirmed in writing for each organisation. In practice it covers the first phase of the work described above: a mapping of your environment, data, integrations and reports, ending in a recommendation and an estimate you can take to the board. The scheme is subject to eligibility and current programme availability; ask for written confirmation of what is covered, which deliverables are included, and whether the assessment is solution-neutral, before you start.
For an organisation that has not started, this is probably the lowest-friction first step: the mapping that must happen anyway, without the budget discussion that usually delays it. Done in October and November, it leaves the plan for 2027 ready before January.
Frequently asked questions about migrating from Fundraising & Engagement
How long does a migration from Fundraising & Engagement take?
The vendor StratusLive, which sells its own replacement solution, estimates that a well-planned migration typically takes three to six months, depending on size and complexity. Where data volumes are large or integrations complex, we plan with six to nine months ourselves, as an experience-based planning assumption. If you have not started by October 2026, plan go-live in the first half of 2027, after the 2026 gift reporting and annual statements have been sent.
What does it cost to migrate from Fundraising & Engagement?
The cost is rarely decided by licences. It is driven by data quality and donor history, the number of integrations to re-establish, reports to recreate, the extent of customisations, and training. An organisation with orderly data, few customisations and one finance integration gets a substantially smaller project than one with years of history, custom workflows and several connected systems. Ask for an estimate based on a concrete mapping of your environment, not a general price list.
Do we lose our donor history in a migration?
No. The core data lives in Dataverse, which continues after the retirement. If you move to another solution on Dynamics 365, the migration is largely a remapping to a new schema inside your own environment. Note that some components, such as payment processing, can hold data in adjacent Azure services; the mapping should cover this. Validating donor history, gifts and campaign associations should still be its own control activity.
Can we keep using Fundraising & Engagement after 31 December 2026?
Microsoft has announced end of support, and the announcement does not say the solution will be switched off on 1 January 2027. After 31 December 2026 it is left without handling of critical security issues, without bug fixes and without support from Microsoft. For an organisation managing donor and personal data, that is a risk that grows every month. A controlled operating period into 2027 with partner support and a fixed migration plan can be a deliberate choice; staying put without a plan should not be.
Is funding available for a migration assessment?
For qualifying organisations, Microsoft funding for a migration assessment may be available through qualified partners; availability and scope must be confirmed in writing for each organisation. The assessment maps your environment, data and integrations and gives you a basis for choosing the path forward. It is a concrete place to start if you have not begun, and it can reduce the cost of the mapping phase. The scheme is subject to eligibility; ask for written confirmation of what is covered.
How does the switch affect gift reporting to the Norwegian Tax Administration?
Organisations in the deduction scheme must submit gift information for the 2026 income year electronically to the Norwegian Tax Administration by 20 January 2027, and no extension is granted. Donors must receive a copy of the information by 15 February. The reporting draws on the full year's donor history, with a national identity number, D number or organisation number per donor. A system change between December and February therefore adds unnecessary risk of errors and rejected records. Our advice is to deliver the 2026 reporting from the current solution or a controlled extract from it, and to place go-live after the annual statements have been sent.
Under three months to the deadline. Where do you stand?
Most organisations do not need a large feasibility study. They need an honest mapping of what is actually in use, a realistic cost picture, and a plan for 2027 that takes giving season and January gift reporting into account. We carry out migration assessments for organisations on Fundraising & Engagement, and help you clarify whether Microsoft funding may be available for the assessment.
Sources
- Microsoft Learn: Fundraising and Engagement is being retired, support ends 31 December 2026
- Microsoft Learn: What is Microsoft Dataverse?
- Microsoft Learn: Power Platform licensing FAQs
- Microsoft Learn: The Dynamics 365 implementation guide (Success by Design)
Sources retrieved and checked 5 October 2026.