Migrations are essentially imports of data into the system. Migrations can either add data (e.g. fill in a blank field on a given number of records), overwrite data (e.g. I already have data in a given field for several records, but I want to replace the data in that field with new data for all of those records), or delete data (e.g. I have data in a given field for several records, and I want to blank out the data in that field for all records).


Migrations are quite complicated and require several pieces of set up, therefore it is generally recommended to use other techniques prior to resorting to a migration. For example, if a Bulk Update can be used to add/overwrite/delete the data instead, it is generally preferable (and easier) to use a Bulk Update rather than a migration. Alternatively, if the number of records is fairly small (a bit arbitrary, but for argument's sake let's say 'small' means less than 25 - 30 records), it may be better to just manually make the updates on the records.

Use Cases for a Migration

As stated above, it in generally recommended to find alternatives to using a migration due to the complications in using one (and therefore the higher probability of making an error while running one). However, there are some cases in which a migration is the preferred option. Migrations are the recommended tool if the use case meets these three criteria:

  1. Large number of records: a larger the number of records makes for a better the use case for a migration. However, a bulk update can also be used to easily update a large number of records, so having many records by itself does NOT make a migration the recommended tool.
  2. Each record needs different data set: When the number of records is large, a bulk update makes your life easy – you can easily, say, update 500 grants such that their Project Title becomes "Test." However, if each grant needs a different project title set on it, e.g., a bulk update is NOT the correct tool as a bulk update can only set data in a field to 1 specific thing for all records. A migration allows you to set different data for each record that is being touched.
  3. The data that needs to be set is not multiple-response: When using the migration tool, multiple-response items CANNOT be updated correctly; instead of setting 2 different values within 1 field, the migration concatenates the two values into 1 value and turns that 1 value into a new option available for selection with that multiple-response field. If you need to set different data on a large number of records for a multiple response item, your only real option is to use Fluxx's API to set the multiple response data.

Setting Up and Using A Migration

Fluxx has a great article that discusses in great detail how to set up a how to use a migration. Please see this article – its contents will NOT be repeated here: https://fluxxdev.atlassian.net/servicedesk/customer/portal/1/article/1796048177?src=-2020772513

  • No labels