Introducing the Migration Accelerator for Apricot: a toolkit that analyzes your Apricot database and gives you a head start on forms, logic, reports, and data migration in Salesforce.
Years of forms, rules and workarounds
Apricot, from Bonterra, is a case management system for human services organizations. Many have run on it for years. Over that time their forms have grown: a field added for a funder, a section hidden by a logic rule, a pick list with “Other” typed in a hundred different ways. The forms work, and staff know them by heart.
When an organization moves to Salesforce, most of the project goes into rediscovering all of that. Someone opens each form, writes down every field, works out which rules show and hide what, and rebuilds it by hand. Then the data migration starts, and the team learns which fields were actually used.
We just finished a migration like this for a multi-program youth and housing services provider. Along the way we built tooling that does most of that rediscovery automatically. We’re now packaging it as the Migration Accelerator for Apricot.
Why Apricot is harder to move than most systems
Most databases are built from tables with named columns: a Clients table with First Name, Date of Birth and Program. Moving that kind of system is mostly a matter of matching column to field.
Apricot is different. It’s a form builder, so its structure lives in metadata. Forms, fields, sections, options and logic rules are all stored as definitions, and each form’s answers sit in a table whose columns are just field numbers. A multi-select answer is one text value with the choices strung together. A link between two forms is a record number. A show-or-hide rule is a set of condition and action rows that point at other fields by number.
None of that means anything until the definitions are read and applied. Before you can say “this question is a required yes/no that only appears for foster youth participants”, you have to piece it together from four or five places. Multiply that by every field on every form, and that’s where Apricot migrations spend their time.
A head start, not a mirror
The goal is to get to a good Salesforce design faster, not to rebuild Apricot inside Salesforce.
- Use the platform’s model. Participants become Contacts, enrollments become program engagements, and landlords and partner agencies become Accounts. Reporting and automation then work across every program.
- Simplify where Apricot needed a workaround. Apricot forms often hold documents in fixed upload slots: “Lease Agreement”, then “Additional Document 1, 2 and 3”. In Salesforce each document becomes its own record with a type and a status, so a participant can have as many as they need, and a missing document can show as “Needed” instead of an empty slot no one notices.
- Surface what was hidden. The analysis shows sections no one fills in, questions answered two ways, and free-text values that should be a list. Those go on a short list to decide with your team.
- Be honest about limits. Some Apricot rules have no exact Lightning equivalent. The accelerator flags each one, so nothing quietly disappears.
Salesforce and Apricot think about data differently, and copying Apricot screen for screen would throw away much of what Salesforce does well. The accelerator handles the translation and gives you a faithful first draft. Then we make deliberate choices with you, for example:
What the accelerator does
The accelerator takes the form definitions alongside the data: fields, sections, options, logic rules, and the columns each form shows in a participant’s document list. It reads those definitions and the data together, so every design decision starts from what your staff actually use.
| In Apricot | In Salesforce | |
|---|---|---|
| Forms and fields | → | Custom objects and fields, created only for fields that hold data or can appear on the form |
| Pick lists | → | Picklist values from the form options plus the values staff really entered, with misspellings cleaned up |
| Logic rules | → | Dynamic Forms visibility on Lightning pages, and validation rules for required questions |
| Sections and layout | → | Page sections in the same order and grouping staff are used to |
| Workflows | → | The logic behind your Apricot workflows, reimagined as user-friendly screen flows that guide staff step by step |
| Programs and enrollments | → | Programs and enrollments in Salesforce program management |
| Reports | → | Salesforce reports with the same columns and filters as your saved Apricot reports, ready to build dashboards on |
| Records, users and files | → | A repeatable, wave-by-wave data load with ownership, history and attachments |
Our process produces a plain-language plan before anything changes: the fields to create, the rules carried over, and the rules that couldn’t be. That plan becomes the agenda for design sessions with your team, so the time goes to decisions with your staff and to designing the most client-centered way for them to work, not to cataloguing fields.
Data migration you can rerun
The same toolkit runs the data migration. Each Apricot form becomes a load step with its own extract, checks and review files. Steps run in waves, so participants load before their enrollments and enrollments before their case notes. Before every load, a check catches the common problems: fields the load user can’t see, picklist values Salesforce will reject, text that’s too long, links that don’t resolve.
Because every step is scripted, the migration can be rehearsed in a sandbox as many times as needed, then run against production with the same results. Staff and records keep their original owners and dates, and the Apricot record ID stays on every row for tracing back.
More of the project goes to what’s new
On our recent project, the accelerator turned many weeks of form analysis into days. It also gave us pages with logic from the forms that we could review with staff instead of designing from scratch.
Getting your data and forms into Salesforce is the starting line, not the finish. The reason to move is what Salesforce makes possible afterwards, and that’s where the time saved goes:
- Better workflows and screens. Guided steps for intake, case notes and exits, and pages built around how each role works rather than around the old forms.
- Data visibility. One participant record across every program, with enrollments, services, documents and history in one place, and sharing set by team and role.
- Reports and dashboards. Caseloads, outcomes and funder reporting that update on their own, for staff, supervisors and leadership.
Those are the conversations we want to spend a project on, with your team, instead of on a field-by-field inventory.
Planning your move off Apricot
The Migration Accelerator for Apricot is an option to include as part of our Salesforce implementation project process.
If your organization is planning a move off Apricot, or wondering how much of your current setup would carry over, please contact us.
Apricot and Bonterra are trademarks of Bonterra. Bigger Boat Consulting is not affiliated with or endorsed by Bonterra.