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 two tabs: a mapping field guide, and the template itself.
Each standard field for the object in question will be listed in the Field column, with a corresponding Data Type, Example, 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. 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. 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 fieldset. If you run into these questions, check in with your Implementation Manager (or submit a case through the Client Community) and we'll point you in the right direction.
To use the Data Template, we recommend either copying and pasting your data directly into the template file, or manually renaming the column headers in your exported legacy file to align with the fields outlined in the mapping guide.
Keep things organized! We recommend that you create your own mapping guide, particular if you've mapped any fields that may have a different naming convention in your legacy system. To do this, add 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!
Before we can import transaction history, we'll first need to create your patron records. 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 how these records interact, and that every Contact must live within an Account. You can learn more about the Account & Contact structure in the All About Contacts and Accounts article.
For the purpose of your data migration, we will only transfer closed, completed Donation records; historical Pledges, Soft Credits, and other outliers can be manually entered into the system as part of your development training. Many development 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.
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!
The Ticket Order template is a little bit more complex, as PatronTicket involves several different objects: Orders, Items, Event Inventory, and in some cases, Payment Transactions. The goal of this template is to primarily provide Ticket Order Items, or the line items from each completed order. Each Ticket Order Item should include at minimum:
- A connection to the patron that placed the order (External Contact ID, or a combination of name, address, and email)
- An External Order ID (required to be able to connect items into a single order)
- Event Name
- Instance Date
We'll use your Event Name, Instance Date, and any other event information that you provide (Allocations, Price Levels, unit prices and fees) to create your historical Event Inventory, based on the tickets that were sold.
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 of how to use this template, submit a case to our Implementation Team first!