Re-Implementation for Social Solutions Apricot 360 and Apricot Core [Video]

Organizations experiencing significant workflow and reporting challenges within their Apricot software may benefit from a system re-implementation.

Re-implementation is the process of designing and implementing a new set of data entry forms to match your organization’s unique workflow, program model and reporting needs.

A re-implementation may sound daunting. In this video we explore the re-implementation process for Apricot 360 and Apricot Core nonprofit database software, specifically:

  • What to expect from your Apricot database
  • 10 key indicators for re-implementation
  • Phases of a re-implementation project
  • Re-implementation approaches and considerations

If you have trouble with system navigation, generating the reports that you need or are examining if Apricot is the right fit for your organization, check out the video below to learn more about re-implementation as a cost-effective solution.


Video Transcript:


Welcome to our webinar, “Apricot Re-Implementation: When to consider it and what it looks like.” Thanks for tuning in.


My name is Keri Stephens. I am an Apricot software consultant at Sidekick Solutions.

Sidekick Solutions is a consulting firm specializing in Social Solutions Apricot software and a leading provider of Apricot customization and support services. We are a Social Solutions Certified Implementation Partner and all of our consultants are Gold Certified Apricot Administrators. We are a remote team, serving clients across the US and the Canadian Rockies, and we are proud to work with nonprofits, collaboratives, and public-sector organizations large and small. I am presenting today from Durham, NC where I live and work.

If you chose to watch this video, you may be struggling with significant workflow and reporting challenges in your Apricot database. You might be examining if Apricot is the right fit for your organization. It may be that you need training, or consulting support and clean up, or you might need a full re-implementation.

A re-implementation may sound daunting. The goal of this video is to equip you with knowledge about re-implementation so that you can make an informed decision about a path forward.

During this video, we will cover:

  • What to expect from your Apricot database
  • When to consider re-implementing in your Apricot (including the top 10 signs you may need to re-implement)
  • What a re-implementation project looks like
  • Several approaches unique to re-implementation projects


Let’s start by reviewing what you should expect from your Apricot database.


Social Solutions’ Apricot™ Core and 360 software is an online database software designed specifically for nonprofits to track and report on a variety of data sets, including clients, programs, services, outcomes, volunteers, and more.


Apricot is a fundamentally flexible and scalable platform: you can configure Apricot to match your organization’s specific workflow, program model and reporting requirements, saving you time on service delivery, data management, and reporting, and maximize the return on investment of the tool.

Your Apricot database should provide users with a logical set of data entry and navigation steps where the data can be reported on using Apricot’s reporting tool. You want it to be robust, yet streamlined and efficient.

What to do if you think your current design isn’t getting you these things? You may want to consider a re-implementation.


What do we mean by re-implementation? Re-implementation is the process of designing and implementing a new set of data entry forms to match your organization’s unique workflow, program model and reporting needs.


There are several indicators of a system redesign need. Here are the top 10:


1. An inability to generate key reports not due to a training barrier – this could be the result of linking issues or missing fields

2. Duplicative data entry – logging the same data in several different locations throughout this system, thus not knowing which data is most current or accurate information

3. Extraneous forms and fields – collecting data that you aren’t really using; usually a result of outdated forms or a 1:1 paper form translation

4. Confusing workflow – navigation with lots of clicks, feeling like you are bouncing around the system

5. Relying on external tools or systems to fill gaps – With any software, there are limitations. However, Apricot is pretty robust so if you feel you are piecing together the things you should be able to to in Apricot with other tools, you likely could benefit from system assessment


6. Independent form sets for each of your programs – A good data design uses shared forms, where possible, which facilitates cross-program reporting on participants served, demographics, service counts, outcomes, etc. It’s a more scalable structure and also helps to standardize staff development/training.

7. Flat rather than dynamic/relational design – Repeat fields in forms indicate a flat design. A dynamic model pulls the unique field set onto a separate linked form to allow for flexibility in record creation and facilitate reporting on those fields by simplifying to a single field reference rather than many

8. Undefined (or over established) relationships between related forms – Linking fields in Apricot connect unassociated forms, allowing users to correlate the linked records in reports. If you are missing links, the report tool will attempt to establish the relationship for you which can yield incorrect pairing of the data in the report rows or duplicate rows

9. Messy or inconsistent data from non-standardized fields – usually a result of open-entry text fields where there could be preset picklists (service provided, goal category, exit reason, etc.)

10. Changes to organizational priorities, programs, and/or reporting requirements since initial system implementation

If any of these ring true in your Apricot database, what should you do next? Switching from one software system to another can be time-consuming and expensive — you may have decided that the resources required to research market options, purchase and customize a new system, then onboard your staff to the new platform is not your preferred route in solving your database challenges.

The good news is that the solution may lie within your current platform. As we previously discussed, Apricot Core and 360 are highly flexible products and offer the tools for customization without the need for a developer.


To be sure that a re-implementation is right for your organization, let’s cover the project steps and requirements.


There are four primary phases to a re-implementation project: assessment, implementation, deployment and maintenance. We’ll review each phase in more detail now.

> Phase 1: System Assessment (“Discovery and Spec”)

If you think you may need a re-implementation, start with an assessment. It is important to be confident that a re-implementation is the best route for your organization, all costs and benefits considered. We recommend finding a consultant for expert advice on your best next steps. Sidekick Solutions starts all re-implementation and system optimization projects with an assessment, and we call this assessment a “Discovery and Spec”.

To do this, we start with an assessment of your current system to identify organizational priorities and reporting requirements, document user feedback/pain points, and uncover configuration gaps and structural issues within your current design.

Then we develop two blueprints:

  1. What your system looks like now
  2. What your system could look like in a vision state relative to your requirements

The goal of an assessment is to compare these two blueprints — line them up side by side and the differences between the two blueprints highlight how to make a transition via re-implementation and the specific recommendations to get you there.

> Phase 2: Implementation

If it is determined that a re-implementation is the best course of action, you would move to phase 2: implementation.

This phase is broken into 3 steps:

  1. Blueprinting – Document submission and interview-style requirements-gathering process driven by your workflow and reporting priorities. Synthesize the information from Discovery into your new system design all the way down to the field level. Impact to existing forms will be clearly documented.
  2. Configuration – Configuration of forms, features and workflow tools (in Apricot 360 and Core this might include Referrals, Workflow, Intake, or Connect)
  3. Testing & Review – your opportunity to preview and test the new system to ensure it meets the requirements. This is where we fine-tune the system before launching.

> Phase 3: Deployment

Following implementation, you will complete go-live planning, set a go-live date, and begin user development and onboarding which may include training, user guides and Q/A sessions.

> Phase 4: Maintenance

Post- go-live, we recommend transitioning into a bridge technical assistance project to support report development (new reports and rebuilds of existing reports), data migration (if necessary), and continued system refinements, phase 2 build outs, and technical support.


Understanding the steps of a re-implementation project may lead to questions around time, resource and competency requirements.

You may be asking what is required of your organization to ensure a successful project? And what is the time involvement?

The following competencies are key to a successful project:

  • Program Knowledge
  • Staff Resources (1:1 time commitment with project lead)
  • Technical expertise (e.g. consultants)
  • Project management (e.g., consultants)

In the example of working with consultants, we do not expect our clients to take on the technical details of Apricot design and configuration, but we do expect our clients to know their programs, service delivery models, operational procedures, and reporting requirements. We collaborate with you to merge our understanding of Apricot’s technical capabilities with your understanding of your organization’s operational models, then drive the end result with seasoned project management.


The timeline for an implementation project depends largely on scope (or # of programs), design and implementation approach (more on this to follow), key operational deadlines and the availability of the entire project team. Projects typically average around 3-6 months.

The scope and scale of your re-implementation project is determined by a number of factors. These decisions are determined by your priorities and the outcomes of the assessment. Let’s look through those decision points.


Re-implementations require a few special considerations since work is being done within a live system that contains real data and active users.


There are two approaches in regards to system deployment: linear and phased.

  1. Linear – Simultaneous implementation of all scoped programs.
  2. Phased – Similar programs implemented in groups over multiple iterations.

Benefits of LINEAR:

  • You can onboard all staff at the same time rather than a split-system usage. This may facilitate adoption.
  • System adjustments identified during build and testing can be reviewed and addressed holistically across all program. In other words, how will this change impact the rest of the system?

Benefits of PHASED:

  • System can be launched more quickly for the priority programs
  • Staff onboarding can be done in phases which may increase manageability
  • There’s an opportunity to improve implementation methods with each iteration through lessons learned
  • Shorter engagement terms are required of project stakeholders

Typically ..

  • Use LINEAR approach for small- to medium-sized implementations
  • Use PHASES approach for large implementations


There are two design approaches when implementing in an active system, each with implications around handling data within the existing framework and managing the user transition to a new system.

  • Independent build
  • Overlay build

An independent build is the configuration of your new form structure independent of the existing form structure. In other words, all current forms will be slated for archive and users will move to the new form structure upon system roll-out.

An overlay build is the configuration of your new form structure overtop/within the existing form structure.

Independent build benefits:

  • No impact to end user experience during configuration
  • Cleaner forms (no hidden fields)
  • Decreases project risk and scope

Overlay build benefits:

  • May be able to continue using some of the existing reports
  • If a migration is desired, it may decrease the scope since some of the data may remain in place
  • If data migration is not needed, data “archived in place” is more easily accessible to end users.

Generally, the independent build approach is used if the new form structure is significantly different from the original form structure and the overlay approach is favorable if the current system design has good “bones” — meaning that current form structure generally supports your needs but modifications to the existing forms and new forms are required.

Your system design team will be able to help you determine which approach is the best fit based on the information gathered in the Assessment and Discovery phases of the project, weighing out the amount of change in the forms as well as your data migration preferences.


Now let’s talk about data migration options.

Migrating your historical data into a new form structure is beneficial because it keeps all of your data together in one contiguous location for clean reporting. On the other hand, data migration projects can be large, require a lot of clean up, and can take time. Fortunately, the scope of data migrations falls on a continuum so there are options in between.

It is important to note that your data will never go away. You will have access to it. What we are talking about here is where historical data will be found in both forms and reports.


  • “Fresh start” or archive in place. This is no data migration; the rollover to new structure is best done at the fiscal year or reporting period break so that you can use prior reports for historical reporting and new reports for future reporting.
  • Migration. Migrating some or all of your historical data from the legacy form structure. An example of a partial data migration would be migrating only the active participants and their associated data.

The fresh start approach is cost- and time-saving. It could also allow your organization to move away from poor data quality that could exist in your historical data.

The primary benefit of a migration is continuity of data. Your historical data is available to end users and you are able to report on historical data in the new reports.
Your system design team will be able to help you weigh the options and determine the best fit for your organization.



Apricot Core and 360 are flexible and customizable. A well designed system should align with your organization’s workflow, program models and reporting requirements.

Navigation and reporting pain points may be indicators of a need for a system redesign. Re-implementing within your current system may save on time, money and end user training.

Re-implementation projects can be complex and have unique considerations. Standardized methodology and expert guidance are available. Start with an assessment.


I hope you found this video helpful. To learn more about Apricot, you can explore our Youtube channel or visit our website. If you like our approach to Apricot software and would like to work with us, send an email to We would love to learn more about your organization and your Apricot to see if working together in a consulting engagement might be a good fit. Our door is always open. Thank you.

Free Download

The Essential Kit to Apricot Best Practices

  • 3x PDF Guides
  • 2x Template/Worksheet
  • 1x 60-minute Webinar
  • ( checklist + slides )

Join the 250+ users that already got their kit!