Planning Your Migration
Four Key Area of Focus
A hosting change for Blackbaud CRM is big decision that requires thorough planning. In this guide, we focus on four key aspects of the migration effort: Environment Design, Project Roles, Inventory, and Timeline.
Understand your current hosting
Many organizations start out hosting Blackbaud CRM with Blackbaud themselves. Over time, increasing needs around integration, visibility, backend access, and custom development drive the need to choose a more flexible hosting solution.
Hosting Blackbaud CRM in-house usually means tight integration with other internal systems. Any new hosting home for Blackbaud CRM must understand the needs around these integrations and offer an alternative that is both resilient and secure.
Early adopters who moved Blackbaud CRM to the public cloud often struggle with nagging performance issues, slow environment refresh times and annoying configuration problems. Security should also be a top concern as staff who DIY a cloud solution usually lack the skills to properly harden and secure cloud instances.
Many hosting providers offer good infrastructure support, but throw their hands up when it comes to support for Blackbaud CRM itself. SQL performance issues prove equally baffling and their recommendations typically involve throwing money and hardware resources at problems.
What is a Migration?
Migration here refers to a hosting change only. In other words, your organization should already be up and running with Blackbaud CRM. Migration from The Raiser's Edge or a similar system to Blackbaud CRM, is a system migration. That is a far more involved undertaking.
If you do not yet have Blackbaud CRM, know this guide could still prove tremendously useful. Keep in mind there is a world of difference between a hosting migration and a system migration.
Organizations with Blackbaud CRM benefit from having more than one environment. Secondary environments consist of a complete installation of Blackbaud CRM yet serve a specific role in support of the primary Production environment.
ENVIRONMENT DESIGN - Number Of environments
How do we know how many environments we should have?
Most organizations have 2 - 4 Blackbaud CRM environments. The answer depends upon the size and of your organization and how much custom development work you do.
Concourse includes an extra environment called Production Sandbox at no additional charge. This environment is used for longer term testing such as major upgrades.
Your main environment with your live data where day-to-day activities take place.
A secondary environment for testing changes and new customizations before deploying them to Production.
A safe environment for training new users or introducing new processes.
An environment used by software developers or third-party vendors to create and test new customizations and integrations.
An exact clone of Production used to test major software upgrades without interrupting the normal Staging to Production release process.
What if Our Blackbaud CRM environments have different names?
You may have secondary environments that go by other names. For example:
- User Acceptance
- Design Configuration
- Configuration Validation
When planning your migration, evaluate which of these environments you still need and if there are any you could say goodbye to. Some environments may be hold-overs from the original system migration to Blackbaud CRM. Sometimes temporary environments get re-purposed. For example, User Acceptance may be synonymous with Staging. Or Configuration Validation may have morphed into Development.
Regardless of the names your organization uses, define a clear purpose for each environment. There’s no sense in migrating environments over that are no longer needed. The migration presents an opportunity to clean house. Everything runs smoother when everyone is on the same page about which environments do what.
ENVIRONMENT DESIGN - Security zones
What are best practices for securing Blackbaud CRM environments from each other?
Security Zones isolate some environments from others. For example, Security Zone A may contain Production and Staging while Development could reside in Security Zone B.
Create Security Zones using 5 layers of security.
#1 - Active Directory
Create distinct Active Directory forests for each Security Zone. Avoid using Active Directory domains in the same Active Directory forest.
#2 - Firewall
Configure each Security Zone with a distinct firewall zone and dedicated firewall interface. Create Security Zones as untrusted firewall zones. This avoids inheriting default rules that might otherwise allow traffic to traverse between the zones.
#3 - VLAN
Create unique VLANs for each Security Zone. Separate VLANs create a layer 2 network boundary. Systems on one VLAN reside on their own network and cannot “see” systems on a separate VLAN.
#4 - IP Address Space
Start by using different internal private subnets for each zone. Separate internal private subnets create a layer 3 network boundary. Avoid sharing public IP addresses across Security Zones.
#5 - Policy
While not a technical security layer like the others, policy is just as essential. It offers crucial context and guidance around the technical layers we create. Without a documented point of reference, essential security layers may be removed, if inadvertently.
ENVIRONMENT DESIGN - Isolated Development
Which design offers the best security without overcomplicating things?
Isolated Development offers the simplest design. It is easiest on day-to-day users moving between Production and the Staging and Training environments.
Only users in the Development environment need to work within the “other” Security Zone.
If you are unsure of which design to go with, choose this one.
Security Zone A
Production, Staging, Training
Security Zone B
ENVIRONMENT DESIGN - Isolated Production
Which design offers the tightest security for our Production environment?
This design emphasizes the security and integrity of Production. Day-to-day users may find it more challenging to move between Production and secondary environments.
You face a real potential downside, however. Without good change control processes in place, your secondary environments may end up being treated as some variation on Development.
This design best suits larger organizations with excellent change control processes.
Security Zone A
Security Zone B
Development, Staging, Training
Are Security Zones with 5 layers of security really necessary?
Let's reframe with a different question.
What would you do to prevent a security incident from happening on your watch?
The Security Zone concept relies upon multiple layers of security to ensure isolation. Isolation means just that - no possibility of access whatsoever. By using multiple security layers, we minimize the risk our isolation design can ever be bypassed. Most security implementations rely upon a single security layer – say a firewall rule. However, if that one layer were bypassed, now what?
Design with security as a priority, not an afterthought.
ENVIRONMENT DESIGN - Production Sandbox
What would we use Production Sandbox for?
Use Production Sandbox for testing big changes. For example, a major upgrade of Blackbaud CRM to a new version or patch. Or upgrading SQL Server to a new version. Production Sandbox is better for this kind of testing for two key reasons.
First, it doesn’t disrupt your process for testing other changes because it leaves Staging as-is. This allows for more thorough testing. Your team can take their time, knowing your Staging to Production release process remains unaffected.
Second, the testing is near-foolproof. Production Sandbox is an exact copy. Staging, while close, is not. Therefore, testing an upgrade in Production Sandbox reflects what will happen in Production as well.
Concourse includes the Production Sandbox environment at no additional charge.
Production Sandbox is an exact clone of Production at our secondary data center. While it mirrors the security of Security Zone A, Production Sandbox remains isolated from Production.
Primary Data Center
Secondary Data Center
Review the roles associated with a Blackbaud CRM migration project. Evaluate the roles you can handle in-house and which require outside assistance.
How do I know which roles we should handle in-house?
For organizations that choose Concourse for hosting Blackbaud CRM, these six roles are taken care of for you during the migration:
- Project Manager
- System Builder
- SQL DBA
- Blackbaud CRM Expert
- Security Guru
- Database Wrangler
This leaves these two roles as your responsibility:
- Software Developer
For organizations that outsource software development, that leaves you with testing as the only role to focus on!
Project roles - Project ManaGer
What tool should we use for tracking the migration project?
A migration project includes a surprising amount of complexity. Use a dedicated project management tool to track everything.
We prefer Basecamp because of its simplicity. Basecamp keeps all communication in one place. It also tracks milestones and creates to-do lists.
If you rely on other communication tools like email, important items may get lost. There is something to be said for having a tool that gives focus to one thing.
The Project Manager acts as the traffic cop for the project.
Much of the what the Project Manager does relies upon timing. To keep the project on track, the right tasks need to get completed at the right time. Should the team encounter a delay, the Project Manager works to remove obstacles.
Project roles - System Builder
Which version of SQL Server should we use?
Blackbaud CRM requires Microsoft SQL Server Enterprise Edition.
Blackbaud lists SQL Server 2012, SQL Server 2014 and SQL Server 2016 as all supported. SQL Server 2017 and SQL Server 2019 are not supported.
However, SQL Server 2012 and SQL Server 2014 reached end of life with Microsoft in 2017 and 2019 respectively.
This leaves SQL Server 2016 as your only option!
Be sure to install SP2 with SQL Server 2016 as this version/service pack combo remains the only one still receiving support updates from Microsoft.
Concourse recommends Windows 2016 and SQL Server 2016 Enterprise Edition SP2 CU8 or later.
The System Builder creates and configures the systems where Blackbaud CRM will be installed.
Start by becoming familiar with the system requirements for Blackbaud CRM and its related systems (as of January 2020).
Blackbaud lists Windows Server 2012 R2 or Windows Server 2016 as supported operating systems. Windows 2019 is not supported.
As for other components, you will also need NET Framework 4.7.1 and PowerShell 5.0.
PowerShell 5.0 comes installed by default with Windows Server 2016. If using Windows Server 2012 R2, PowerShell 5.0 must be installed separately.
Project roles - SQL DBA
What is more important for Blackbaud CRM SQL Servers - CPU or RAM?
If you must choose between the two, RAM is more important. A SQL Server with a slower processor but lots of RAM will perform well, just slower. A SQL Server with a fast processor yet inadequate RAM will perform terribly.
Most organizations under provision RAM on their primary Blackbaud SQL Server by a factor of 2 or 3. Simply adding more RAM can go a long way to help smooth out the rough edges of Blackbaud CRM performance.
We also see many organizations over provision CPU cores with the mistaken belief that more cores will make Blackbaud CRM "go faster". More cores allow for more concurrency, not faster speeds. Instead, pay special attention to your options for the speed of the processor and choose the fastest processor possible.
The SQL DBA configures and optimizes your SQL Server instances for Blackbaud CRM.
Be sure to follow the best practice when setting up different disk drives for SQL Server as follows:
- Operating system (C: drive)
- Database log files (R: drive)
- Database data files (S: drive)
- TempDB files (T: drive)
Also, don't forget that Blackbaud CRM requires a high degree of concurrency. Optimize for high concurrency by modifying the following values:
- Cost Threshold for Parallelism: 50
- Max Degree of Parallelism: Follow this advice from Microsoft
What about SQL monitoring for Blackbaud CRM?
Would you drive a car at night with no lights? Or fly an airplane in the mountains with no guidance system?
Unfortunately, this is exactly how most organizations with Blackbaud CRM operate – with virtually no SQL Server monitoring whatsoever. Most organizations rely upon ad-hoc manual monitoring efforts leading to haphazard responses.
SQL Server monitoring helps eliminate costly surprises and gives crucial visibility into exactly what’s going on inside your Blackbaud CRM databases.
Included At No Additional Charge When hosting Blackbaud CRM With Concourse
SQL Sentry by Sentry One
To be effective, SQL Server monitoring must be continuous, consistent, and logged. Tracking and recording of key metrics over time also provides valuable historical data that helps diagnose and troubleshoot.
SQL Sentry is our preferred tool here at Concourse for SQL monitoring. SQL Sentry tracks detailed and actionable metrics that directly help your team keep on top of SQL issues such as:
- High-impact queries
- Query tuning
- Buffer pool usage
- Missing and unused indexes
- System resource usage
- Storage utilization and trends
Concourse includes SQL Sentry as part of our overall monitoring solution for its Blackbaud CRM customers.
Project roles - Blackbaud CRM Expert
Wouldn't we need to hire somebody for this role?
If you host with Concourse - no. Otherwise, yes.
At Concourse, our team can install, configure, and migrate every aspect of Blackbaud CRM.
Otherwise, plan on using Blackbaud Professional Services for this aspect of the project.
Budget for having the services of the Blackbaud CRM Expert throughout the duration of the migration project. They'll be needed to troubleshoot and fix things on short notice.
Of course, once you are ready for your final go live, have the Blackbaud Expert on the ready to ensure that final step goes smoothly.
Blackbaud CRM Expert
Installation of Blackbaud CRM is not easy to say the least. A misconfiguration here or best practice not followed there leads to trouble down the road. Only entrust this role to somebody with experience doing Blackbaud CRM installations.
The Blackbaud CRM Expert understands how to install and configure all the various components of Blackbaud CRM.
Each Blackbaud CRM environment needs to be configured separately. And each one may have some aspect that is different than the others.
Project roles - Security Guru
Should our internal security teams be involved in the migration project?
Start with your organization’s security policy for guidance. Specific requirements around security vary between organizations, but policies should be informed by an industry standard such as PCI DSS or HIPAA.
Our team at Concourse speaks the language of your internal security team and can work directly with them to answer questions and help ensure your Blackbaud CRM instances are well guarded and secured.
The Security Guru ensures all aspects of Blackbaud CRM get configured securely.
For those organizations that choose Concourse as their hosting partner for Blackbaud CRM, this project role is completed by our staff.
Concourse undergoes audits conducted by an outside security firm on an annual basis. Our last audit for the following was completed Q1 2020:
- PCI DSS 3.2 as a Level One Service Provider
- Validation of Compliance with HIPAA Security Standards and HITECH Act, which are comprised of the Administrative, Technical, and Physical Safeguards along with the Organizational Requirements and the Policies, Procedures and Documentation Requirements.
Isn't cloud hosting secure by default?
The toolbox in your garage cannot fix your car on its own much less tighten a screw by itself. The cloud may have all kinds of fancy tools available, but without somebody to configure and monitor them, your cloud hosting is no more secure than any other hosting option.
In fact, a false sense of security that cloud hosting is secure by default is far more dangerous. Some organizations hope to escape the scrutiny of their internal security teams by "hiding" applications in the public cloud. Without the necessary budget and personnel to protect public cloud-hosted assets, such organizations are asking for trouble.
Review the checklist below for important security elements recommended for Blackbaud CRM installations:
- Firewall configuration
- IDS/IPS configuration and monitoring
- System hardening
- Scheduling regular patches and updates
- Vulnerability testing (external and internal)
- Permissions for users, groups, roles
- Password complexity, reset, and lockout policies
- Two-factor authentication
- Tracking access for power and admin users
- SSL certificates, ciphers, and protocols
- Log monitoring (SIEM)
- Anti-virus (yes, servers need it)
Project roles - Software developer
What if our developers want to work directly with our Production or Staging environments?
Software developers should work in their own Development Blackbaud CRM environment. Access to Production should be off-limits to developers as a matter of policy and enforced in practice.
If this has not been the case for your organization in the past, the migration presents the perfect opportunity to set things up according to best practices!
The Software Developer role could mean staff employed by your organization or an independent consultant. It could also be third-party vendors like BrightVine, Zuri Group, Omatic Software, Zeidman Development or SmartThing. And, of course, Blackbaud themselves. (Concourse does not provide custom software development services for Blackbaud CRM - we only do hosting!)
Consult with everyone who is doing software development to understand the tools and access levels they need.
Project roles - Tester
What causes testing during a migration project to go off the rails?
Many factors can contribute to this.
Organizations may lack a plan of exactly what to test. Sometimes they underestimate the amount of time needed for testing. We also see a tendency to exclude staff doing the testing from the project outset. Thus, when testing starts, those team members must play catch-up.
The Tester role is crucial. Get this right and you will have a smooth migration. Get it wrong and the whole project stands at risk.
Unfortunately, despite warnings to the contrary, time and time again, migration project after migration project, we see delays due to a lack of adequate testing.
Check out the Hand Off Phase of the Timeline section below for tips on testing success.
Pyramid of Migration Testing Success
Project roles - Database Wrangler
What are the common database migration problems?
- Confusion over responsibilities
- Old copy of database sent
- Backup which depends upon other backups
- Incomplete or partial backup
- Database transfer too slow
- Database transfer fails repeatedly
- Database transferred across multiple hops
- Database compatibility mismatch
- Incompatible transfer software
- Incompatible encryption method
- Incompatible compression method
The Database Wrangler has one job: ensure the Blackbaud CRM database gets transferred intact and in a timely manner for the final migration.
It may seem strange to assign a role just for this purpose. Yet far too many migrations go sideways during the final database migration for a variety of reasons.
The last thing you want is to have a great migration project only to have the final migration end up a nightmare.
We focus on the following six inventory aspects of your Blackbaud CRM.
Virtual server or physical server?
In the age of cloud computing, virtualization technology provides the platform upon which cloud services are delivered. Concourse features VMware vSphere Enterprise Plus with High Availability version 6.7 U3 as our private cloud platform.
For purposes of this guide, the word “server” is synonymous with virtual server or virtual machine running a single operating system instance. We refer to the physical hardware upon which many virtual machines run as a host.
All but the smallest Blackbaud CRM installations with Concourse get dedicated factory new physical hardware (the host) upon which run all your virtual machines (the servers). Thus the physical resources of your host remain dedicated to running just your servers. Larger organizations often require two or more hosts: one for the Production environment servers or even just the Production SQL servers, and another for secondary Blackbaud CRM environments.
Inventory - Servers
What's the recommended number of servers for a Blackbaud CRM environment?
Servers should have one role and one role only. Don't make two or three servers and cram everything onto them. Each Blackbaud CRM environment requires three SQL servers just for the various database needs.
A typical configuration includes 5 servers per environment and 4 servers common across all environments for that Security Zone.
Adding a second environment to a Security Zone would add 5 more servers. For example, an environment design with a single Security Zone containing the 3 environments of Production, Staging and Training would have 9 + 5 + 5 = 19 servers.
Adding another environment in a different Security Zone adds 9 more servers. For example, an environment design with 2 Security Zones containing Production in one and Development and Staging in the other would have 9 + 9 + 5 = 24 servers.
- Domain Controller
- Load Balancer
- Remote Desktop Gateway
- Remote Desktop Session Host
- BBIS Application Server
- CRM Application Server
- Primary SQL Server (OLTP)
- Data Warehouse SQL Server (OLAP)
- SQL Server Reporting Services (SSRS)
Inventory - STORAGE
Does the the type of storage matter?
If possible, get all-flash storage such as SAS (fast) or NVMe (faster). If you cannot afford the fastest storage for all servers across all environments, split storage needs between primary storage and secondary storage.
Primary storage refers to high performance storage needed for day-to-day operations. Secondary storage is lower performance such a spinning disk or a hybrid between spinning disk and flash.
If nothing else, be sure to get the fastest storage possible for your Production SQL server.
When sizing drives be sure to allocate plenty of extra space for growth. If a drive fills up on the Primary SQL server, the entire system can go down.
While storage use tends to grow steadily over time, it can also grow in unpredictable bursts. Focus on keeping at least 50% extra disk space available, especially for your database servers. Trigger an alert if disk space drops below 25% free for any SQL drive.
SQL TempDB can experience explosive growth in a short period of time. A big export or data moving process can quickly chew up hundreds of GB of disk space. For best performance, Microsoft recommends TempDB be split into multiple files, depending upon the CPU allocation to the server. Once you have those files in place, make them as big as possible by following this guidance from Brent Ozar.
How can I make Blackbaud CRM use less storage space?
Blackbaud CRM uses a tremendous amount of disk space that grows and grows and grows over time. It seems that keeping the database size below a certain level is fighting a losing battle.
Perhaps it is.
Ask yourself why is it important to keep the database below a certain size? Is the size creating a measurable performance problem? Or is this a random expectation that the database simply seems too big because "we don't have that much data"?
The truth is that the size of the database matters very little.
Of course, your organization should keep your Blackbaud CRM database organized and clean by archiving or removing irrelevant data. However, data cleaning should always 1000% of the time be driven by a need for organizational efficiency and never because "drives are filling up".
Buy bigger drives. Or better yet, get more efficient storage that compresses and deduplicates the data. If you're letting disk space drive your organizational priorities, you're spending time on the wrong thing.
In the meantime, stop stressing out over the size of your database. As long as the database performs well, you're fine.
Inventory - DNS and SSL
What are the common FQDNs associated with Blackbaud CRM implementations?
Contact the IT resource who manages your DNS. Obtain a complete list of all FQDNs (Fully Qualified Domain Names) used for Blackbaud CRM, BBIS as well as any other Internet-facing service end points.
- CRM Application
- All BBIS Sites
- Reporting Services
- Remote Desktop Gateway
- Third party application endpoints
- Integration APIs
- Secure FTP Server
Cross reference this list against the same thing from your Blackbaud CRM data services team. Check for gaps. Namely, FQDNs that nobody can account for.
Unaccounted for FQDNs mean one of two things. It could be an active FQDN that was missed. Or it’s stale and no longer used.
Either way, present the cross-referenced list to the migration team. Each FQDN directly associated with Blackbaud CRM will need to be updated. After the migration, unused entries may be safely removed.
Keep an eye open for anything that points directly to a back-end server. That’s a security red flag. A migration presents an opportunity to fix things that previously may not have been setup in the best way. Turn to the project’s Security Guru for guidance.
Who should handle all the SSL certificates? Somebody from our team? Or somebody from the hosting provider?
Each FQDN requires an SSL certificate issued by trusted Certificate Authority (CA). Even if your team managed SSL certificates in the past, consider passing this responsibility to the hosting provider. Your internal team may not be familiar with important nuances associated with modern SSL certificates. For example, SAN and EV options.
Furthermore, as of September 1, 2020, all SSL certificates expire after one year. That means a lot more administrative hassle in renewing certs and another reason to let the hosting provider manage this for you.
After each SSL certificate gets installed, verify its security with a service like SSL Labs which tests the proper configuration of supporting encryption ciphers and protocols.
Require all publicly facing FQDNs receive at least an “A” rating
Inventory - Customizations
How do I know which customizations to get and where they reside?
Get copies of all the files associated with all the various types of customizations you may have.
Be sure to keep the files organized according to the path location they reside. When in doubt, simply grab all the files from your Blackbaud CRM installation.
CRM and/or BBIS application servers:
- Custom DLLs
- Custom HTML
- Custom CSS
- Custom images
Data Warehouse Server:
- Custom Integration Services packages
- Data Warehouse extensions
Reporting Services Server:
- Custom RDL files (export these)
Blackbaud CRM utilizes a single database that resides on the Primary SQL Server. Aside from that main database, some organizations may have extra custom databases for reporting or other purposes.
Take a second look at all side databases and assess where each should reside. When possible, consider relocating side databases off the Primary SQL Server and onto the Data Warehouse Server.
Blackbaud CRM gives your Primary SQL Server more than enough to do. Avoid using it for extra side databases as much as possible. Side databases that do reporting pull valuable system resources away from Blackbaud CRM and can impact performance.
Inventory - Integrations
How are integrations different from customizations?
Integrations refer to separate non-Blackbaud applications that connect with Blackbaud CRM.
Plan on enlisting the support or professional services from the company specific to the application. They will need to be involved during the initial configuration of the new environments and then again after final go-live.
Sometimes the application you want to integrate with resides within a different hosting environment.
We recommend using Stunnel as the preferred method to connect systems on disparate networks.
Stunnel is superior to site-to-site VPN because the VPN connects too much - typically an entire subnet. Connecting subnets in this fashion essentially places the connected subnets on each other's network which has huge security compliance implications.
Because Stunnel only connects systems on certain ports, it's more like adding a firewall rule than a VPN tunnel. Therefore, its security impact is lightweight.
Do you need a Proof-of-Concept project?
Does your Blackbaud CRM rely upon complex integrations and legacy dependencies? Or perhaps a component that only one or two team members know the ins and outs of?
Occasionally, migration projects keep getting pushed out because it would break integrations with X, Y and Z. Instead, it may be appropriate to spin up a separate Proof-of-Concept (POC) project.
A POC project allows the opportunity for team members to explore possible solutions without the pressure of a deadline in the middle of a migration. The POC project can work like a mini-migration project. However, it does allow for experimentation and looking outside-the-box for new solutions.
Be sure the POC project has adequate resources to accomplish its goals. If your team finds themselves stuck, consider bringing in outside consultants. Also, research how other organizations handle similar dependencies.
There's always more than one way to do things. Just because the integration worked a certain way before doesn’t mean that’s the only way it can be.
Once the POC clears a path forward, the migration becomes possible.
Inventory - Authentication
How should Blackbaud CRM Active Directory accounts be configured?
Blackbaud CRM integrates with the same Active Directory domain as the system on which it's installed. It connects with users in this domain automatically. You can even add new users to Active Directory from within Blackbaud CRM itself.
If your organization chooses to use this native Active Directory for user accounts, decide if you want the naming convention for user accounts in the new domain you are migrating to. If so, this may make it easier on users. After the migration, they’ll only have to reset their password.
Of course, you can always change up the username format if you don't like the old naming convention. For example, organizations that migrate from vendor hosted Blackbaud CRM typically have their Blackbaud site ID tacked onto their username. For example, fjones34234.
Also be sure the domain is properly configured with a password policy endorsed by a well-known security standard such as PCI DSS.
- Password complexity (Upper case, lower case, number, special character)
- Password length (7 character minimum)
- Password expiration (every 90 days minimum)
- Password history (cannot re-use same password as last 4)
- Account lockout (6 failed attempts in 30 minutes locks account for 30 minutes)
Have a password reset website available to users so they can reset their passwords.
Many organizations who have Blackbaud CRM prefer to manage Active Directory in house. But if your Blackbaud CRM is hosted elsewhere, you have a decision to make; how are your users going to authenticate?
Fortunately, you can add remote authentication as an option for authenticating your Blackbaud CRM users. Remote authentication doesn't replace the native Active Directory integration but merely adds to it.
You have two options available: Blackbaud's own tool or one developed by Zuri Group. At Concourse, we have customers using both of these methods.
If your organization does not have an IdP (Identity Provider) and you simply want to connect to a remote Active Directory, use Blackbaud's free tool called ADAuthenticator. It's a simple deployment using an IIS web server on the remote Active Directory domain. For added security, add a firewall rule that restricts access to only Blackbaud CRM.
On the other hand, if your organization does have an IdP and you’re looking for a method that’s more “plug and play,” Zuri Group's SSO for BBCRM is going to be up your alley. There is an additional cost for this option.
Your Blackbaud CRM migration project will progress through the following 5 phases.
Timeline - Kickoff
Steps of the Kickoff Phase
- Introduce the team to each other
- Invite everyone to Basecamp
- Set a weekly meeting time
- Set the tone and expectations
The Kickoff Phase should only take 1 week
Communication. Communication. Communication.
Communication provides the foundation for project success. Include everyone including testers from the outset of the Blackbaud CRM migration project.
Enforce weekly meetings during the project. Make sure all team members understand that attendance at the migration team meetings is mandatory.
These weekly meetings provide an essential opportunity for team members to talk things through. We always marvel at how often problems get solved simply by putting people together at the same table (virtual or otherwise).
Timeline - Build
Steps of the Build Phase
- Create servers
- Install and configure applications
- Communicate any issues that arise
- Assign resources to tackle troublesome issues
The Build Phase takes 3 - 8 weeks depending upon the number of environments and overall complexity.
And we're building...
It's critical for team members performing various tasks of the Build Phase to give regular and detailed status reports as to their progress. This way any issues that are encountered are communicated immediately.
Team members not directly involved in the Build Phase may feel like there's nothing to do. However, it's important everyone remain involved. You never know when somebody's feedback might help overcome an obstacle.
How long should our timeline be?
Most organizations can migrate Blackbaud CRM within 12 - 24 weeks.
Focus on the planning process. In other words, how you plan matters more than the plan itself. Migration projects struggle when a small number of team members try to develop “the plan” in a vaccuum.
This is what you don't want to hear...
“Migration? What migration? Nobody told me.”
“This is all wrong. You would have known that if you asked in the first place.”
“Did anyone talk to Carol? She’s the only one who understands how that process works.”
By including everyone's input from the start, you not only come up with a more complete plan, you win their loyalty. Ignore them, you earn their skepticism, possibly followed by resistance.
Consult with everyone who will be involved with or even impacted by the migration. One week the team may decide to do one thing. The next week they may change their mind and do something different based upon new information.
Don’t trust the plan. Trust your planning process.
Timeline - Hand Off
Steps of the Hand Off Phase
- Formal hand off to testers
- Ensure all testers have accounts and access
- Testers run through their checklists
- Detailed feedback provided
The Hand Off Phase can take from 2 - 6 weeks and largely depends upon the preparation and availability of your testers.
It's testing time!
Support your testers well from the outset. This cannot be emphasized enough. Ensure testers are testing and not waiting around for help with basic issues like password resets or not having the proper access. If you have a lot of testers, assign a specific person as their go-to resource for support.
Make sure testers understand expectations around reporting errors. Don't accept incomplete testing feedback like "page won't load" or "got an error". Give examples of helpful error reporting with steps to reproduce and wording of the exact error message. Better yet, train your testers on Step Recorder and let the tool do the work of taking screenshots.
Timeline - Fix
Steps of the Fix Phase
- Team works together to resolve issues
- Re-test as needed
- Categorize issues by go or no go
- Re-adjust project timeline as needed
The Fix Phase usually needs 4 - 6 weeks because this is where any gaps in planning and testing emerge.
It's time for bug squashing! And also surprises...
The Fix Phase is also where you'll hear the phrase "oh yeah that" perhaps more than you like. Despite best laid plans, there always seem to be things that crop up that were not previously considered. Processes with special requirements. An integration nobody realized was an integration. A custom setting in a web.config. Plan as you might, some surprises are simply inevitable.
This phase goes quicker if you schedule special deep-dive sessions where subject matter experts meet with testers to work through troublesome issues. A one hour deep-dive session might save weeks of back and forth.
Who knows, with a few of these sessions you might just make this migration project look easy!
Timeline - Go Live
Steps of the Go Live Phase
- Create a go-live checklist
- Do a dry run first
- Ensure key staff are available
The Go Live Phase including a dry run typically takes 2 - 3 weeks.
The final go-live most likely involves DNS changes. These changes may need to be made by somebody who hasn't been involved in the project to date. Make sure your inventory includes a thorough understanding of such changes and who will be doing them.
If possible, include a dry run before your final migration. This gives everyone including your Database Wrangler (remember them?) a chance to run through the go-live checklist.
It's been a long process to get this far. Congratulate yourself and everyone on the team.
Have some cake!
Would you like some help walking through this guide together?
Let us help you put together some pieces of the migration puzzle. Together we'll develop a migration plan which can serve as your jumping off point once you're ready for a migration.
Click on the button above to sign up for our free Blackbaud CRM Migration Walk-Through.