Moving from BBNC to Almabase: The Assisted Fast Pass Migration

Blackbaud is sunsetting support for Raiser’s Edge NXT’s database view and related functionality in September 2027. Learn how Almabase replaces your current functionality and how our Assisted Fast Pass Migration makes for a smooth switch without disrupting your campaigns or operations.

Anwesha Kiran

Updated: 

September 27, 2026

Summary

Recent global disruptions — pandemics, economic shocks, social justice movements, and political divides — have reshaped our innate need for genuine connection and belonging. When education human interactions become unbridled, they need to show how engagement translates into real participation, better retention, and long-term giving. Just tracking activity numbers doesn't cut it anymore. And as alumni populations become more diverse and scattered across the globe, the playbook must evolve to keep up.

Blackbaud recently announced that support for Raiser’s Edge NXT’s database view and related functionality will end on September 15, 2027, affecting several Blackbaud products. These include Blackbaud Online Express and Blackbaud NetCommunity (BBNC). For advancement teams that have spent years building forms, pages, workflows, and other processes around the platform, this means choosing and migrating to a new platform. The prospect can feel like a lot to take on, especially if it wasn't something you'd anticipated.

If you're looking for an alternative, Almabase can help you replace the functionality you currently rely on across these products. We've already covered why teams might be thinking of a move off BBNC and how the main alternatives compare. In this article, we’ll be focusing on what happens once you've made that decision: what the migration process looks like, what your team can expect along the way, and how Almabase approaches the move.

In case you’re evaluating how Almabase stacks up against BBNC, check out our comparison blog here.

There’s also another question that comes up around a platform migration: How much is this going to cost?
This question extends beyond the immediate, visible technical costs. In fact, the technical side of the move might just be the simplest to figure out. It’s the broader, more abstract elements like shifting scopes, changing requirements, or even figuring out the right set of requirements in the first place that could end up costing the most amount of money and time, if not approached thoughtfully.

That's why we want to walk you through the Assisted Fast Pass Migration process upfront: what happens at each stage, what your team is responsible for, what our migration team handles, and where costs may come into the picture. We hope to give you a clear idea of what the move to Almabase will look like before you get started, so there are fewer surprises along the way.

Why transparency matters during a migration

A migration project always begins with an agreed-upon plan. But it’s also very likely that, a few weeks in, you discover a form that needs some additional customization or a request that seemed straightforward seems to fall outside the original scope, on second thought. These are perfectly reasonable hiccups during the migration, but if work is already underway, it could seem harder to understand what you're paying for, and even harder to plan around the rest of the project.

Clear expectations are at the heart of our migration approach, starting with total transparency around what extra requirements cost. With Almabase’s Assisted Fast Pass Migration, each stage gives you a chance to understand what's being proposed, what falls within the standard migration, and where something would require additional work.

Basically, you shouldn't find out about an extra requirement after the work has already been done. Your approval and sign-off comes first. The five steps in the migration process are built around this intention. Let’s get into them.

1. Kickoff: Getting the project off on the right foot

The migration process starts with a kickoff between your team, a dedicated CSM, and an implementation specialist. This is where we get the groundwork in place. This is usually access to your current site, your branding assets, and the dates your team needs to work around.

Another important step here is understanding your calendar and priorities. Your Giving Day, reunion, fiscal year-end, or another major event may determine what needs to happen first and we would be building the migration calendar around it. So, the migration sequence might look a little different for each institution, as each gets to choose which product goes first.

The kickoff is also a chance to flag anything unusual about your current NetCommunity setup.

After years on a platform, it's normal for your setup to have accumulated a few workarounds, custom configurations, or integrations that made sense when they were created. We don't need to solve all of those questions in the first meeting, but we do need to know about them.

That way, we can account for them during the next stage: the inventory. 🤗

Your team mainly needs to provide:

  • Key dates and deadlines
  • Relevant branding assets
  • Access to your existing NetCommunity site
  • Any known custom configurations, integrations, or unusual workflows
  • From there, you can let us take on the heavy lifting.

Your dedicated CSM and implementation specialist work with you throughout the migration, while your team focuses on the decisions and approvals. A migration shouldn't require your advancement team to take on managing a project full time on top of everything else they’re already handling.

Your data doesn't have to wait for the build

Your data migration is handled alongside the rest of the process. Almabase's bi-directional TrueSync integration connects with Raiser's Edge NXT and supports two-way syncing for configured entities and fields, including constituent, event, and gift data.

Admins can also decide which fields update automatically and which should be reviewed before they're pushed or pulled between systems.

That means your team doesn't have to wait until every page and workflow decision has been finalized before thinking about what happens to your data. The data side of the transition can move forward alongside the rest of the migration, with real time decisions being made.

2. Discovery and inventory: weeks one and two

Once kickoff is complete, your implementation specialist carefully starts building a complete inventory of what's currently running on NetCommunity: pages, forms, events, programs, memberships, and other key components of your site.

This process is useful in its own right, especially when taken on by someone external. After years on a platform, it's easy for a site to accumulate things that no one thinks about anymore, simply because they’re too involved in the process. The inventory gives you one place to see what's actually there, anything you might’ve forgotten about, and to make decisions about what needs to move vs what can be left behind.

Probably the most effective part of this is that it's a shared inventory that you can review alongside your specialist. If something looks outdated, doesn't need to move, or needs a closer look, you can flag it before it moves to the new product.

The inventory can surface things like:

  • Duplicate or unused event pages
  • Old forms or pages that are still live
  • Site elements that don't need to be carried into Almabase
  • Custom fields and configurations that don’t make sense on the new platform

This idea is to document your NetCommunity site so well that both teams end up on the same picture of what exists and what needs to happen next. The Almabase team handles the actual inventory work, and all you need to do is review the inventory and flag anything that should be changed, removed, or investigated.

3. Sign-off: deciding what moves forward

At this stage, the migration project starts taking on a more defined shape as you decide what you need to bring into Almabase. You and your implementation specialist review the inventory, decide what carries forward, and establish what the finished version should look like.

For each item being migrated, the team, along with you, defines the acceptance criteria before the building begins. If your existing alumni directory has eight fields and three filters, for example, those requirements can be documented as part of the scope. By the end of this discussion, everyone has arrived at the same definition of what needs to be delivered.

This is also where you’ll be able to clearly separate standard migration work from anything that requires additional effort.

If something falls outside the standard scope, you'll know before the work begins:

  • What the additional work involves
  • What's included and what's excluded
  • The estimated effort
  • The associated cost

You won’t have to decipher this from the invoice later on, because the work only moves forward once you’ve signed off on the scope.

This is exactly why your input here matters most. The Almabase team handles the building, but it’s you and your team deciding what is important enough to carry forward and what “done” needs to look like, within the standard process or with additional effort layered on.

4. Build and launch: 30 days for each product

Our team takes up building only once you’ve greenlit the scope. Each product gets its own dedicated 30-day track, with the order of products taken up built around your events and fiscal calendar.

This is to accommodate your calendar: giving days, reunions, Homecoming, we’ll build that product first so you’re ready in time for go-live day. If your immediate priority is your broader alumni site, we might begin with building that instead. The point is, even at this pace, you’re not forced to adopt a one-size-fits-all solution. Your implementation team works with you to determine what needs to come first.

The build itself happens on your Almabase pages, so you can review as it gets built while also familiarizing yourself with the new platform.

The timeline typically looks like this:

  • 30-day build track: Each product moves through its own focused build.
  • Weekly working session: Your team meets with the implementation team to review progress, provide input, and make decisions.
  • Training as you go: Your team gets hands-on experience with the platform during the build, rather than waiting until everything is finished to start learning it.
  • First launch: The fastest migrations can have their first product live around 45 days from kickoff, depending on the scope and sequencing of your project.

Having the scope agreed upon shows up in smoothness at this point: you can expect fewer decisions to make from scratch during this stage. Your team knows what's being built, your implementation specialist knows what they're working toward, and everything can move as planned, on track.

5. Cutover: moving from NetCommunity to Almabase

As you get closer to launch, the focus shifts from building to making the transition itself as smooth as possible.

The most important part of that is making sure people can still find the things they've been using. Your team receives a redirect map that pairs each carried-forward NetCommunity URL with its new Almabase destination. You'll also want to review where those old links appear outside NetCommunity: your main institutional website, email templates, QR codes, printed materials, and any other places where an old URL may still be in circulation.

The redirect map gives you a clear list of what needs to change and no one has to discover old links one by one after launch.

Before each product goes live, your team gets to review it thoroughly and explicitly approve the launch.

The aim, with these five steps, is to get your Almabase programs ready before your NetCommunity access ends, so the transition remains smooth and doesn't become a last-minute scramble.

What happens when something doesn't fit the standard scope?

Not everything that comes up during a migration falls neatly into the original plan. But there's also an important conversation to be had: what counts as additional scope and what is a limitation in the platform itself?

If something requires work beyond the standard migration scope, that's identified and quoted before the work begins. You can then decide whether you want to take it on.

But if there’s a requirement you have that Almabase cannot support yet, we’ll be fully transparent with you. Essentially, you haven’t asked for too much, we’re just not there yet. Depending on what you need, the team can look at a workaround or determine how the functionality could be addressed after launch.

This conversation is also one of the reasons the earlier stages matter. The shared inventory, defined acceptance criteria, and upfront scoping give everyone a common reference point throughout the project.

That's really the principle behind the entire migration process. You're not expected to know every detail of what needs to happen before the project starts. The process itself is designed to show you those details early, give your team a chance to make the calls that matter, and keep the build moving while minimizing unexpected, last-minute surprises.

Ready to make the move?

A BBNC migration may not have been on your roadmap, but that also doesn't mean it has to become a project that takes over your team's calendar.

With a clear process, an agreed scope, and the right support, you can move the parts of NetCommunity that matter to your team and work for your institution without having to figure everything out as you go. The Almabase team handles the build and migration work, while your team stays in complete control of the decisions, priorities, and final approvals.

And because the scope and any additional costs are addressed before the work happens, you can go into the migration knowing what to expect.

If you're planning your move away from BBNC, let's talk about what it could look like for your institution.

Talk to the Almabase team about your BBNC migration →

Assisted Fast Pass Migration from BBNC to Almabase

Table of Contents

Subscribe

See how modern advancement teams bring alumni engagement and fundraising together.

Plan faster. Execute better

Explore free templates designed for alumni and fundraising teams.

Anwesha Kiran

Anwesha is an educator and pedagogy enthusiast, passionate about the transformative impact of education, kindness, and creativity on individuals and communities.

As an artist, she brings a unique perspective to her work and is committed to inspiring growth, empathy, and understanding

Get a closer look at how modern advancement teams use Almabase to engage, raise, and retain

Book a demo