This guide is aimed at helping you make a smooth transition from Blendo to RudderStack. It will familiarize you with the differences you are likely to encounter during the migration in terms of functionalities and the UI.

Migration-specific Differences

Users are likely to encounter the following scenarios when migrating from Blendo to RudderStack:

• The first time you create a source on RudderStack, all the historical data associated with that source will be fetched again by RudderStack. This is done to ensure the consistency of the data. RudderStack will not charge you for the volume of this initial sync.

• The process of setting up a data pipeline in is slightly different in RudderStack. You will have to add a source, a destination and then explicitly link the two. This approach will give you more flexibility and the ability to connect a single source to multiple destination platforms.

Source Functionalities

In terms of functionality of the sources, you are likely to encounter the following differences in RudderStack:

• The sources in RudderStack will continue executing the data import tasks, even if the data from the previous imports has not been exported to any destination/s.

Data Structure Differences

The following differences are observed in the data structure of the sources in RudderStack:

• In Blendo, various fields present in the imported data that contain date or time values were annotated and formatted as timestamp columns in the destination warehouse tables. However, this feature is currently not supported in the RudderStack sources. As a result, these fields will be exported according to their JSON representation, as provided by the external API.

• The special columns blendo_imported_at, blendo_exported_at will no longer be populated at the destination. The context fields will be included in each event to provide the segmentation of data. The list of context fields introduced in RudderStack are:
  • context_sources_job_id - Corresponding to the source ID, as it appears in the RudderStack UI.
  • context_sources_task_id - This is the resource name - e.g. 'lists', 'contacts', etc.
  • context_sources_job_run_id - Corresponds to a unique ID assigned to a single execution of the source import process.
  • context_sources_task_run_id - This is a unique ID assigned to a single execution of a specific source task.
• Resources that replaced the previous data on export are no longer supported. In RudderStack, the new data will always be appended to the output table. This change affects mainly two resources: Google Sheets rows, and Mailchimp lists.
• Prefixing tables on destinations is not supported by RudderStack. You can resolve the conflicts in table names from sources of the same role by exporting to separate schemas.

Functionalities to be Released Soon

We're currently working on adding more functionalities to make the migration from Blendo to RudderStack more seamless. Some of them are:

• Currently, the failures encountered in the import tasks are only displayed in the RudderStack UI. We are working on adding support for error notification, so that you get timely alerts in such a scenario.
• The RudderStack UI will also have a usage report that includes the details related to the data imported by the source.
• We are working on improving the performance of the data pipelines, compared to Blendo. In case you have come across any performance-related differences between Blendo and RudderStack, feel free to contact us.

Contact us

For queries on any of the sections covered in this guide, you can contact us or start a conversation in our Slack community.