Use this link to share with your colleagues:
Data Migration Templates: https://help.pm.leapevent.tech/a/1263736
The first major step of your data transfer will be to "box up" your records and label them for the move. When submitting your data for migration, our Data Team may require that your data is formatted into one of our templates prior to submission.
Our data migration templates will serve as a mapping guide to provide clear labels for the destination of each piece of data between your old system and PatronManager. This article includes links to commonly-used templates, as well as general guidelines for formatting data into these templates:
Understanding the Data Template
Each data template that we provide represents an Object in PatronManager, such as Accounts, Contacts, Donations, or Ticket Orders. Within each template, you'll find a few tabs: an information page, mapping field guide, and template with example data.
Each standard field will be listed in the Field column, with a corresponding Salesforce Object, Data Type, Example, Default Value, and any pertinent Notes:
1. Field: These are the names of the fields that you will see in PatronManager. While we can add custom fields to this list as needed, the available standard fields should cover the vast majority of information that you'll need to transfer from your legacy system. Your job will be to identify the name of the column header from your legacy export and match it up (or "map" it) with the corresponding PatronManager field name.
2. Salesforce Object: Salesforce provides a powerful database structure made up of objects. These objects define different sets of data, and objects relate to each other so you can reference related data. Some examples of objects are Contacts, Accounts, Ticket Orders, and Donations.
3. Data Type: The type of information that can be input into each field will be defined by the Data Type:
- Text(255) This type of field can accept any text value, with a limited number of characters specified in parenthesis
- Date This type can hold values that are listed in date format (mm/dd/yyyy)
- Date/Time Similar to "Date" format, this type can hold values that are listed in date+time format (mm/dd/yyyy hh:mm am/pm); if no time is specified, the system will default to 12:00 AM
- Phone/Fax This type will accept numeric values only, which will display in the traditional North American phone format in the system: (xxx) xxx-xxxx
- Email This type will only accept text values that are in email address format: [email protected]
- Checkbox This type will be displayed as a checkbox in PatronManager, and can accept either True/False or Yes/No entries to note whether the box is checked or unchecked
- URL This type will accept text values that are in URL format, and will display an active hyperlink in PatronManager
- Lookup(Contact) In PatronManager, this will be a hyperlink to a related record. For the purpose of our templates, we will typically ask for an External ID to a record to make this connection.
3. Example: We've provided a few examples to give some context to each Field and Data Type, to make it easier to digest and compare to your legacy data set.
4. Default value if not provided: Some fields have constant defaults (noted in bold), while others will use defaults if you don't provide data. If you have questions about the default values, please ask your Data Specialist or Implementation Manager.
5. Notes: We'll provide additional notes if there's additional context or rules that you'll need to know as you prepare your data.
Not sure where your legacy data belongs? In some cases, you may find that you have additional records to migrate that don't fit into the template, or that you have additional fields that don't match up to our standard field set. If you run into these questions, check in with your Data Specialist or Implementation Manager and we'll point you in the right direction.
Remember that the templates provide you with all available fields that exist in PatronManager. You are not required to provide data for each field listed outside of the required (highlighted) fields!
Instead of copying and pasting your data directly into the template file, we recommend that you manually renaming the column headers in your exported legacy file to align with the fields outlined in the template/mapping guide.
Keep things organized! We recommend that you create a column to the Field Mapping file and enter the names of the columns from your legacy system as they correspond with each PatronManager field.
Do I really need to provide External IDs?
A critical piece of information to pull from any legacy system during your data migration will be the External ID from your database. Most databases will have a unique ID for each record in the system - whether that's a patron's contact record, ticket order, or even individual journal entries for a transaction. Some systems will make this ID easily accessible through reporting, while others may keep it disclosed for backend or system administrator use only.
We will ask for an External ID for each record, as this makes it much clearer to connect records during the data migration process. Without the presence of an External Account or Contact ID, you may need to provide additional contact information (such as name, email address, or mailing address) for us to make an accurate connection between a transaction record and the patron that made the purchase.
Where can I download the current templates?
Right here!
In this template, you'll see references to two objects: Accounts and Contacts. Contact records represent the individual patrons that interact with your organization, which are then organized into Accounts. It's important to understand that every Contact must live within an Account, and every Account must have at least one Contact. You can learn more about the Account & Contact structure in the All About Contacts and Accounts article.
If you collect patron information in more than one database, please submit a separate report from each system. Our team will run a basic deduplication of all Accounts and Contacts following the import.
The format of this file (or files) should be laid out as one Account per row, with each Contact for a given Account residing in the same row.
In this template, you'll see references to the Donation and Contact objects. Contact information does not live on the Donation record itself, but the two are linked.
We will only import closed, completed Donation records; open Pledges, pending Recurring Donations, Soft Credits, and other outliers can be manually entered into the system as part of your development training. Many fundraising systems will include all donations in a single export file; if this is the case, we recommend either filtering these gifts out, or sorting and extracting these specific types of gifts from your report and organizing them in separate files to manually enter at a later date.
If you track donations in multiple systems, you may submit a separate donation report from each system; however, please ensure that there is no duplication of transactions between files.
The format of this file (or files) should be a transaction-based report, with one Donation per row.
We have a few templates available for transferring Memberships, depending on how your organization intends to process new Memberships and Benefits in PatronManager.
We recommend the traditional PMGR Membership Template for most configurations. This template utilizes the Membership module as it was originally intended in PatronManager, which involves selling Memberships in a similar manner to Ticketable Events, where each Membership has a set price and is processed as ticketable income. However, we recognize that some organizations consider their Memberships as donated income, in which case we will set up a Membership record type in the Donations module.
Not sure which of these applies to your organization? Submit a case to our Implementation Team and we'll help you figure it out!
In some cases, you may only want to grant Benefits to a list of patrons - we've got you covered here!
This template references several different objects: Items, Orders, Event Inventory, and Contacts. Items (tickets) make up an Order. Contact information lives on the Order and a Contact record is also linked (like with Donations). Event Inventory will be created for all events included in this data.
We will only import final ticket orders to past events; refunded or exchanged tickets should NOT be included. When removing refunds from your data set, it’s important that you also remove the initial purchase as well, so we don’t import incorrect data.
Tickets to future events will be imported later during the gap data migration (if the events occur before your Tickets On Sale Date). For events that won’t occur until after your Tickets On Sale Date, the tickets will need to be manually entered into the system.
The format of this file (or files) should be a transaction-based report containing one item (ticket) per row.
This template is primarily used by existing PatronManager clients that have a need to import a large amount of event data to their Event Inventory at one time, such as a Film Festival or Timed Admissions for a museum. If you're unsure how to use this template, submit a case to our Implementation Team first!