Migrating Your Data

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.

Process

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
    questions
  • 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:

Pricing

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.

Data

Customers

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.

Attribute

Description

customer.old_provider_id

Unique identifier for each customer.

customer.email

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.

customer.display_name

(Optional) The display name that can be used by the customer

customer.password

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).

customer.common_metadata.password_encryption

The type of encryption used to encrypt the provided passwords.

customer.common_metadata.import_only_the_customer

Referring to if this migration will import only customers data and meta data.

customer.old_provider_id

customer.email

customer.first_name

customer.last_name

customer.title

customer.display_name

customer.salutation

customer.password

customer.common_metadata.import_only_the_customer

customer.common_metadata.password_encryption

customer.common_metadata.stripe_object_id

abcd_14327

[email protected]

Genaro

Cassano

Mr.

G.Cassano

Dear Sir

$S$E787NL98gqdILAPnprFDzXuXzJjSMttvx8l.YNcEqtM7rvMJZpsJ

0

md5

123123

Products

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.

Attribute

Description

product.id

Unique identifier for every product, used to relate product data with plans data.

product.address_required

Boolean value that indicates if the customer address is a must to have this product (1) or not (0).
In case of taxes inclusion in payments, addresses are required for all eligible customers regardless of product nature.

product.name

The product name for this product.id.

product.description

(Optional)Further details about the product.

product.id

product.address_required

product.active

product.description

product.name

abcd_memberships1

1

1

Print + Digital

Gold

Plans

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.

Attribute

Description

plan.amount

The unit amount in cents to be charged, represented as a whole integer if possible.

plan.auto_renew

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.

plan.interval

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.

plan.interval_count

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).

plan.shipments_per_interval

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.

plan.common_metadata.temporary_product_id

The associated product id with this plan.

plan.common_metadata.temporary_id

Unique identifier for each plan.

plan.group_owner_plan_id

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,

plan.entitlements

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)

plan.amount

plan.auto_renew

plan.currency

plan.interval

plan.interval_count

plan.nickname

plan.shipments_per_interval

plan.description

plan.common_metadata.account_name

plan.common_metadata.temporary_product_id

plan.common_metadata.temporary_id

4500

1

eur

4

1

Membership-Gold-eur

12

Print+Digital

abcd

14371

1234

Addresses

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).

Countries in address should be in the 2-letter ISO standard format, you can find details here, also states should be filled for Canada and US in the 2-letter ISO standard format just like here.

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 :-

address.billing_first_name

address.billing_last_name

address.billing_line1

address.billing_line2

address.billing_city

address.billing_state

address.billing_country

address.billing_salutation

address.billing_title

address.billing_zip

address.billing_phone

address.billing_company

address.billing_department

address.shipping_first_name

address.shipping_last_name

Genaro

Cassano

C/ Canarias 42

Ormaiztegi

Guipúzcoa

ES

Dear Sir

Mr.

20216

(+34)-655-5893

AB_Productions

Accounting

Genaro

Cassano

address.shipping_line1

address.shipping_line2

address.shipping_city

address.shipping_state

address.shipping_country

address.shipping_salutation

address.shipping_title

address.shipping_zip

address.shipping_phone

address.shipping_company

address.shipping_department

C/ Canarias 42

Ormaiztegi

Guipúzcoa

ES

Dear Sir

Mr.

20216

(+34)-655-5893

AB_Productions

Accounting

Subscriptions

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.

Attribute

Description

subscription.current_period_end

(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.

subscription.cancel_at_period_end

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.

subscription.shipments_undeliverable

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.

subscription.shipments_suspended_until

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.

subscription.shipments_remaining

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.

subscription.quantity

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.

subscription.collection_method

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).

subscription.common_metadata.temporary_plan_id

Associated plan_id with a given subscription.

subscription.common_metadata.old_id

Unique subscription identifier. This field is optional but in case of having gift subscriptions it must be filled.

subscription.common_metadata.service_status

Status of a given subscription which could have one of the following values (active or unpaid).

subscription.common_metadata.is_gift_donor

Boolean value indicates whether this subscription is related to gift donor (1) or not (0).
Added only in case of migrating gift subscriptions.

subscription.common_metadata.is_gift_recipient

Boolean value indicates whether this subscription is related to gift recipient (1) or not (0).
Added only in case of migrating gift subscriptions.

subscription.common_metadata.gift_donor_subscription_id

The donor subscription id associated with the recipient subscription. This value should be filled for the recipient.
Added only in case of migrating gift subscriptions.

subscription.current_period_end

sunbscription.cancel_at_period_end

subscription.start_date

subscription.shipments_undeliverable

subscription.shipments_suspended_until

subscription.quantity

subscription.shipments_remaining

subscription.quantity

subscription.collection_method

subscription.common_metadata.temporary_plan_id

subscription.common_metadata.old_id

subscription.common_metadata.is_expired

subscription.common_metadata.service_status

subscription.common_metadata.order_number

subscription.common_metadata.order_price

31/01/2021

0

31/01/2020

1

1

1

1

1234

1012131

0

active

12233

4500

Cancelled/Expired subscriptions

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.

Undeliverable

It is possible to mark subscriptions as un-deliverable

Quantity

We can migrate subscription quantities in the migration.

Gifts

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