Last week, we talked about what Luminate CRM means to nonprofits, and reasons why they leave. This week, in a longer-than-usual fashion, we’ll review some basics for preparing to leave, how to start the departure, and tactics for what and where to go.
What to Consider When Leaving Luminate
Leaving Luminate CRM may sound straightforward. An organization’s data is inside of Salesforce already, and Salesforce can accept additional managed packages and customizations to move it out of the Luminate garden and into a replacement ecosystem. However, a number of additional considerations and “gotchas” come into play:
- Luminate (and all Common Ground variations) generally cannot be uninstalled, despite being part of the managed package program. Meaning that you will need to move to a new Salesforce instance and start over. There are rare exceptions to this, but they require substantial time to re-configure, along with the potential assistance of Salesforce.com technical support.
- Moving to a new Salesforce instance will require money for licensing during the transition, consideration of API limits moving data into the new instance, re-adding all installed applications, rebuilding custom Objects that your organization built, and rebuilding reports based on a new data architecture.
- All data from Luminate managed package fields and Objects needs to find new homes, unless it is being discarded or archived outside of Salesforce.
- Business processes designed to support specific Luminate CRM ecosystem features will need to change. Your organization may find it needs to revisit and redo policies and practices heretofore assumed to be de rigor.
- Not all custom Objects from Luminate CRM will have direct correlations to those from other tools, requiring strategic data mapping and business process re-building.
- Data entry processes will change and users will require re-training.
- The user experience will also change, and require acclimation to a new visual, contextual, and hierarchical assignment of your data.
- All Luminate Online components will need to be replaced with separate integrated tools, each requiring their own ramp up time and business processes to support.
- Each new third-party integration into a Salesforce environment will require consideration of its effects on other components, as these are no longer managed by a single entity.
- Staff administration and data management time will change.
It will be helpful to organizations to undergo an evaluation of the components of the Luminate ecosystem that are most helpful for conducting business, that still meet mission-driven needs, and ultimately provide meaningful data moving forward. Not everything should be replaced – especially if an organization’s mission, programming, fundraising strategies, or other needs have changed. Questions organizations can ask as they leave that will be helpful guideposts on the way include:
- How much of the Luminate ecosystem am I using? What do we love and can’t live without? What doesn’t work and needs replacement? And what works but is complicated and needs to be unraveled as we move to a new Salesforce instance?
- What data is actually important? Does the metrics it contains still meet our mission?
- How much data do we actually have? Data complexity and movement to a new instance is one consideration, but also sheer volume will require time to export, clean, remap, and re-upload into a new instance. Don’t expect to move gigabytes of information in a day or even a week.
- Do we need all of these features from Luminate, or only think we do?
- How much time and money do we have for a replacement?
- How much will staff capacity and roles need to change to continue moving forward with the same level of Salesforce use and integrated tools?
- What other departments need to use Salesforce and how?
- How long can my organization subsist with its primary database offline? This will give you a sense of your migration window.
- Can your Web services continue to collect information such as custom Web site integrations, online donations, email subscriptions and sends, and other functions and easily sync to a new Salesforce instance while your migration takes place?
- Will specific online services, such as donation processing and email/marketing automation need to be replaced first so that outreach functionality can continue while the database is migrated?
- How will data between old and new tools, and information from the legacy Luminate ecosystem need to be transformed, normalized and de-duplicated as it’s migrated?
- What are our new organizational goals and strategic plan? Does the new platform meet these, or are you just rebuilding what was there, instead of what is or will be?
How to Leave
Understanding business processes and data map structure is key for departure success. Treating a migration out of the Luminate ecosystem as a standard implementation project is a mistake – you will absolutely need to have an implementation partner with deep business process analysis and strategic capabilities, and time and space, for your organization to consider how it does business in the absence of the structure Luminate CRM provides. This understanding and analysis will be vital to placing Luminate CRM data in a new Salesforce instance. Training, and re-training, will also be substantial components to helping users make the changeover and continue successful long-term adoption.
Also, don’t forget to allow your organization to have a moment to let go of that which has changed – let folks feel sad that their favorite perk is no longer available, or that their responsibilities are shifting. Allow space for the full gamut of change and transition-related feelings, good and bad. Leaving the garden is scary and new, as much as it is awesome and fun.
A few things you can do now to start this process:
- Give yourself a lot of time. This is true for any implementation, but especially true here. You will need to revise how your organization acts with Salesforce, and there’s always going to be a “gotcha.” Make sure you’re not hinging completion on an artificial parameter such as, “We must do this by our Spring fundraiser.” A moderately used Luminate CRM instance migration can take as much as six months of real time to fully transform – a lot depends on data use, quality, integrated tools, business processes and practices, and other factors.
- Prepare for a lot of data evaluation and migration. You’re likely going to need to move to a new Salesforce instance, and even if you don’t, you’re still going to need to move your data out of all the managed package fields and features. Let go of “little darlings,” especially when preserving the legacy data doesn’t serve future needs, or create easy ways of summarizing legacy information in the new Salesforce instance that may never need full reporting consideration in the future. Ask yourself, “Do I just want to see or have this at my fingertips, or am I going to be relating this information to future organizational and reporting needs?”
- The Undiscovered Country. You may find that departments or people, who have been unwilling or unable to challenge the status quo, suddenly have new requirements, needs, and wishlist items that you didn’t realize existed because they didn’t have the opportunity to express them or have them considered while using Luminate.
- Take a look at “System Overview” and see how much data is kept where. Extreme amounts of information stored in any Object(s) will point to areas where you need to be especially mindful of mapping and migration. Pay attention to the custom Objects from Luminate CRM: many of these will require replacement, from Donation Designations to Contact Classification Types, Partial Soft Credits and TeamRaiser. Remember to ask how much literal need you have for these things, and don’t simply assume that because you’re using them now, you’ll need to rebuild their functions. Do you need to see every embedded bit of data in them, or just know that people and organizations participated in them, when you move to your new Salesforce instance?
- Once you’ve evaluated how much data resides in which Objects, install Field Trip and determine how many fields within each of these Objects you’re actually using. Field Trip can also be used to form your initial data map out of Luminate CRM: it gives quantity, type and other useful information about every field it touches. Field Trip data forms a component of those conversations about what you want versus your real needs are, and what you’re using simply because it’s there.
- Liberal use of formula fields can help with test data extracts and evaluations. Create Case Safe ID fields on all the Objects you’ll be migrating, in addition to the standard Record ID fields, to help with using data extract tools. Create formula fields in Salesforce to pull parent record IDs on to child records (or through multiple child records). Although this isn’t strictly necessary in all cases, it can help immensely with data extraction and matching. Don’t be afraid to preserve former record ID information in the new Salesforce instance, it will give you a reference point for validating data between the two instances during and after migration.
- What kinds of custom, unmanaged package, or other Apex Classes and Triggers are in your instance? Will they be required once you leave Luminate CRM? How much code coverage do they have, and will it be sufficient to re-deploy them in an new Salesforce instance now that code coverage requirements are at 75%?
- What kinds of workflows, templates, and other declarative features are you using? Why? Will they require rebuilding as well?
- Custom Visualforce, other non-Convio/Blackbaud tool integrations, custom Web site integrations, and any other customizations that you’ve built for yourself will need to be evaluated, documented, and potentially re-built as part of the departure from Luminate CRM.
- Use the amazing free tools available to nonprofits: DemandTools and Apsona, notably. However, for deep pulls of your instance Object trees, Apex Classes/Triggers and other components, also consider Eclipse.
- Remember that there are new features and functions directly on the Salesforce platform that can replace old ways: notably, Process Builder, as a replacement for many circumstances where one might have considered using Apex code.
Where to Go?
Depending on your needs, you have options and places to go that require various amounts of ongoing time, administration and cost that can be combined together to best meet new requirements and mission-driven direction.
- Community-sourced and supported tools: The Nonprofit Starter Pack and many free tools available to nonprofits can be put together to meet your needs. Going this route will generally require more administration time and compatibility testing, as well as making sure your organization has someone(s) moving forward who is responsible for keeping abreast of the changes and evolutions of all these tools.
- Combining new vendor-supported tools and packages: Good examples of these include Affinaquest, Causeview, StayClassy, Soapbox Engage, and many others. There’s no guarantee that everything will “play nice” together, since you’re now outside the walled garden. But, using one or more of these tools does give you a place to call when something goes wrong, with the cautionary tale that the response may be, “it’s not our tool causing the problem, it’s this other thing.” You will still need to have someone(s) responsible for the vendor relationships, management and long-term care of these solutions at your organization.
- Another wide-scale integrated ecosystem on Salesforce: You may determine that the best option for your organization will be leaving Luminate CRM for another single-vendor managed ecosystem for fundraising. You will still undergo substantial change and data migration, and there will be a long-tail of adoption support, but sometimes the cost to build and adopt multiple separate tools is greater than going to another pre-built solution, and this is valid for many organizations.
When You’re Done
Lastly, remember that when you’re done, you’re not “Done.” All of the principles and premise of change/transition management, starting small and thinking big, developing an organization wide system of peer-to-peer training, governance of your Salesforce instance, and the myriad of other ways by which Salesforce is implemented for the long haul still apply.
Take this opportunity to build Salesforce into your organization the same way you would build human resource management, volunteer management, donor/funder cultivation management and all the other vital executive leadership functions that nonprofits need to act. Cloud technology, as part of the overall necessity of IT management and deployment, is a fundamental part of nonprofit operations in the 21st century, and Salesforce for nonprofits a vibrant component of nonprofit operations.
Special thanks to TJ Warfield, Director of Information Technology at Save the Bay, for her insights and contributions to this series.