Migrations into the platform is a complex process that requires the data to be normalized and transformed to fit our structure. In this section, we outline all the main objects required to successfully migrate your data into Pelcro.
Our support team is right there for you!
Contact us at [email protected] and we're happy to assist with any questions or concerns.
If you are looking to migrate from another service or platform into Pelcro, we can help you with that. The migration team has a deep understanding of relational databases that they have used to successfully migrate hundreds of thousands of subscriptions across several businesses. We have migrated businesses from several other systems that include but are not limited to CDS, Piano, PayPal, Braintree, TownNews, Pigeon, Pico, and ClickShare. It typically takes two weeks to analyze the data and prepare for its migration. Note that any technical team of developers would be able to successfully migrate data into Pelcro using the API. You can learn more about the API here.
Below is an overview of the migration steps:
- Data request will be made from the old provider to analyze the data
- The migration team will provide a report of all data that will be migrated along with any
- The data will then be migrated into a testing environment that will be made available to the
publisher along with a migration analysis report
- You will run tests on the staging data and provide consent to then move forward
- Migration date will be set and an up-to-date copy of the data will be expected on that date
- Credit card data migration will be initiated if necessary from one PCI provider to another directly. Once the migration of cards is complete, a mapping file will be provided to us in order to map the credit card to its associated customer and subscription. The mapping process will be done by our team to ensure that any auto-renewed subscriptions are maintained.
The old provider must ensure that a unique identifier for each user is provided as metadata in the mapping file and the same unique identifier must be included and used in the main migration data dump which is sent to us.
*On the migration day, your old provider will be temporarily put on hold until the migration is complete. Note that for larger migrations, we are able to migrate a delta, however, depending on the situation, additional fees may apply for migrating delta files.
Below is a list of migration requirements:
- Customer-related properties
- Product and plan related properties
- Subscription related properties
It will be required from your team to retrieve all the data required for the migration and make it available to Pelcro’s migration team. It will also be required by your team to validate the migration analysis report.
IMPORTANT: It is critical to provide a customer, address and subscription data in one flat file while providing another flat file for the products and plans.
The associated templates can be found here:
- Pelcro migration template for customer data
- Pelcro migration template for plans
- Pelcro migration template for products
A migration process typically is priced on time and material. The more assistance we can get from your team, the quicker the process can be. If you can provide us the data in predefined CSV files, we will be able to process the migration in less time. However, if you provide us a data dump that we have to analyze, the process will take longer. Another factor will also be the quantity of the data. Get in touch with the sales team if you need you are looking for a quote.
Customers are the underlying customer that we associate subscriptions, payments, invoices, and more to. Customers' migration can be done for customers who have an active subscription and also customers who don't have an active subscription. Customers can also be migrated to registered users.
Any additional custom metadata fields that may be added should be customer-based, this means that those metadata values are unique per customer.
You can learn more about the Customer (User) resource and its associated properties.
Here's a list of the typical information which is vitally needed for a given customers migration, as well as an example of a sample dataset.
Unique identifier for each customer.
The related email for this old_provider_id. This email should be unique per old_provider_id which means that same email shouldn't be shared among more than one customer or vice versa.
(Optional) The display name that can be used by the customer
In case of password migrations, encrypted passwords should be provided for all customers (note that for completing password migrations , a subset/sample of encrypted passwords should be provided with their corresponding plain text passwords).
The type of encryption used to encrypt the provided passwords.
Referring to if this migration will import only customers data and meta data.
Product objects describe items that your customers can subscribe to with a Subscription. A product can contain multiple pricing plans.
You can learn more about the Product resource and its associated properties.
Here's a list of the typical information which is vitally needed for a given products migration, as well as an example of a sample dataset.
Unique identifier for every product, used to relate product data with plans data.
Boolean value that indicates if the customer address is a must to have this product (1) or not (0).
The product name for this product.id.
(Optional)Further details about the product.
Print + Digital
A Plan determines the pricing of the product. For example, a digital subscription can be created as a product and can have a monthly $5 pricing plan and a $20 yearly pricing plan.
You can learn more about the Plan resource and its associated properties.
Here's a list of the typical information which is vitally needed for a given plans migration, as well as an example of a sample dataset.
The unit amount in cents to be charged, represented as a whole integer if possible.
This dictates whether a subscription assigned to this plan will auto-renew or not when the subscription is initiated. The subscription can go back to auto-renew separately.
The frequency at which a subscription is billed. Can be one of the following options: day, week, month, or year, represented as 1,2,3,4 respectively.
The number of intervals (specified in the interval attribute) between subscription billings. For example, interval=3( represents Month) and interval_count=3 , this bills every 3 months. and if interval count changed to be 12 , this will bill yearly (every 12 months).
The number of shipments per interval. This value will get decremented on every approved fulfilment by one on the subscription and will re-added once the invoice is regenerated every new interval. for example in the below table, interval is yearly while it's a monthly print, so the shipments per interval are 12.
The associated product id with this plan.
Unique identifier for each plan.
In case of having group subscriptions, this field should be filled only for group user plans, representing the related group owner plan id for this group user plan,
In case of single plan having multiple entitlements, this field should be added and filled with the multiple entitlements separated by a comma (e.g. ent_a,ent_b,ent_c)
Addresses defines all the required contact information for customer , including a full address , company information (if any) , phone and zip code . This data is essential for both shipping and billing also (in case of offline billing scheme or taxes inclusion).
Address is said to be complete when it has at least (Line1,City(and state in case of US and Canada),Country and zip code).
In case of same customer has more than one unique address, Pelcro will migrate only the 1st one and discard others.
Note: The default customer address is set to shipping address details.
You can learn more about the Addresses resource and its associated properties.
Below is a one-row sample of plans' data for migration :-
C/ Canarias 42
C/ Canarias 42
Subscriptions allow you to charge a customer on a recurring basis. A subscription automatically creates an invoice at each interval renewal.
Below are some points to consider while migrating subscriptions:
- Same customer(old_provider_id) could have multiple subscriptions normally.
- Same pair of (old_provider_id & plan_id) couldn't be repeated multiple times with different data, and if this happen the first record only will be migrated while others would be discarded.
- During migration, the "cancel_at_period_end" field would be the main source of truth for subscription auto-renewal, this means that if this field indicates that this subscription is non auto-renewed while the related plan has a 'plan.auto_renew' value of '1', the subscription would be non auto-renewed regardless of the plan auto-renewal value and vice versa.
You can learn more about the Subscription resource and its associated properties.
Here's a list of the typical information which is vitally needed for a given subscriptions migration, as well as an example of a sample dataset.
(Date) End of the current period that the subscription has been invoiced for. At the end of this period, a new invoice will be created.
Boolean attribute that you can use to determine whether a subscription that has a status of active is scheduled to be cancelled at the end of the current period. for example if this subscription is associated with auto-renewed plan , this value would be set to 0 as it wouldn't be cancelled at the period end.
Sets the subscription on an undeliverable mode, this can then be filtered out when creating a list. This is helpful if this customer is not receiving the shipment for any reason, and you want to make sure future shipments are not lost.
Sets the subscription on a suspension mode, this can then be filtered out when creating a list. This is helpful if customers are traveling and request a suspension till they are back for example.
The number of shipments remaining on a given subscription as of the migration date. Normally when creating the new interval invoice shipments_per_interval from the plan is added to the shipments_remaining amount, this occurs on the first invoice of the plan but also on all subsequent invoices that are created automatically by the subscription.
Depending on the associated product/plan, some subscriptions may require a quantity for the product/service provided (e.g. in the case of print subscriptions where the subscriber has required to include a specific number of copies per shipment). In most cases, this value should be set to 1.
This attribute has only 2 possible values: "charge_automatically" and "send_invoice", referring to the subscription payment method, whether it is charged automatically by credit card or by sending the invoice (e.g. via check or wire payments).
Associated plan_id with a given subscription.
Unique subscription identifier. This field is optional but in case of having gift subscriptions it must be filled.
Status of a given subscription which could have one of the following values (active or unpaid).
Boolean value indicates whether this subscription is related to gift donor (1) or not (0).
Boolean value indicates whether this subscription is related to gift recipient (1) or not (0).
The donor subscription id associated with the recipient subscription. This value should be filled for the recipient.
In order to retain historical attributes that allow you to segment your customers and subscribers based on them, we can migrate certain attributes such as subscription start date and other important customer attributes. It is not possible to migrate any cancelled or expired subscriptions. It is also not possible to migrate any historical billing information. All this data can be sent to us for storage in our backups that can be queried in the future upon request.
It is possible to mark subscriptions as un-deliverable
We can migrate subscription quantities in the migration.
We can migrate gifts, however, in order to migrate the relation between donors and recipients, it will be at an additional cost.
This relation would be handled through adding and filling the gift columns (subscription.common_metadata.is_gift_donor, subscription.common_metadata.is_gift_recipient, subscription.common_metadata.gift_donor_subscription_id) as shown in subscription attributes description table above.
Check out these helpful articles for more information on our blog
Updated 18 days ago