diff --git a/docs/cli.html b/docs/cli.html index 00b46b3dd..5fab24377 100644 --- a/docs/cli.html +++ b/docs/cli.html @@ -791,7 +791,14 @@
Migrate a percentage of users or a single user from one version of your integration to another.
-
Usage: zapier migrate FROMVERSION TOVERSION [PERCENT]
Start a migration to move users between different versions of your integration. You may also "revert" by simply swapping the from/to verion strings in the command line arguments (i.e. zapier migrate 1.0.1 1.0.0
).
Only use this command to migrate users between non-breaking versions, use zapier deprecate
if you have breaking changes!
Migration time varies based on the number of affected Zaps. Be patient and check zapier jobs
to track the status. Or use zapier history
if you want to see older jobs.
Since a migration is only for non-breaking changes, users are not emailed about the update/migration. It will be a transparent process for them.
We recommend migrating a small subset of users first, via the percent argument, then watching error logs of the new version for any sort of odd behavior. When you feel confident there are no bugs, go ahead and migrate everyone. If you see unexpected errors, you can revert.
You can migrate a specific user's Zaps by using --user
(i.e. zapier migrate 1.0.0 1.0.1 --user=user@example.com
). This will migrate Zaps that are private for that user. Zaps that are shared across the team, shared app connections, or in a team/company account will not be migrated.
Alternatively, you can pass the --account
flag, (i.e. zapier migrate 1.0.0 1.0.1 --account=account@example.com
). This will migrate all Zaps owned by the user, Private & Shared, within all accounts for which the specified user is a member.
The --account
flag should be used cautiously as it can break shared Zaps for other users in Team or Enterprise accounts.
You cannot pass both PERCENT
and --user
or --account
.
You cannot pass both --user
and --account
.
Arguments
Usage: zapier migrate FROMVERSION TOVERSION [PERCENT]
Start a migration to move users between different versions of your integration. You may also "revert" by simply swapping the from/to verion strings in the command line arguments (i.e. zapier migrate 1.0.1 1.0.0
).
Only use this command to migrate users between non-breaking versions, use zapier deprecate
if you have breaking changes!
Migration time varies based on the number of affected Zaps. Be patient and check zapier jobs
to track the status. Or use zapier history
if you want to see older jobs.
Since a migration is only for non-breaking changes, users are not emailed about the update/migration. It will be a transparent process for them.
We recommend migrating a small subset of users first, via the percent argument, then watching error logs of the new version for any sort of odd behavior. When you feel confident there are no bugs, go ahead and migrate everyone. If you see unexpected errors, you can revert.
You can migrate a specific user's Zaps by using --user
(i.e. zapier migrate 1.0.0 1.0.1 --user=user@example.com
). This will migrate Zaps that are private for that user. Zaps that are
in a team/company account
+will not be migrated.
Alternatively, you can pass the --account
flag, (i.e. zapier migrate 1.0.0 1.0.1 --account=account@example.com
). This will migrate all Zaps owned by the user, Private & Shared, within all accounts for which the specified user is a member.
The --account
flag should be used cautiously as it can break shared Zaps for other users in Team or Enterprise accounts.
You cannot pass both PERCENT
and --user
or --account
.
You cannot pass both --user
and --account
.
Arguments
fromVersion
| The version FROM which to migrate users.toVersion
| The version TO which to migrate users.percent
| Percentage (between 1 and 100) of users to migrate.Migrate a percentage of users or a single user from one version of your integration to another.
-
Usage: zapier migrate FROMVERSION TOVERSION [PERCENT]
Start a migration to move users between different versions of your integration. You may also "revert" by simply swapping the from/to verion strings in the command line arguments (i.e. zapier migrate 1.0.1 1.0.0
).
Only use this command to migrate users between non-breaking versions, use zapier deprecate
if you have breaking changes!
Migration time varies based on the number of affected Zaps. Be patient and check zapier jobs
to track the status. Or use zapier history
if you want to see older jobs.
Since a migration is only for non-breaking changes, users are not emailed about the update/migration. It will be a transparent process for them.
We recommend migrating a small subset of users first, via the percent argument, then watching error logs of the new version for any sort of odd behavior. When you feel confident there are no bugs, go ahead and migrate everyone. If you see unexpected errors, you can revert.
You can migrate a specific user's Zaps by using --user
(i.e. zapier migrate 1.0.0 1.0.1 --user=user@example.com
). This will migrate Zaps that are private for that user. Zaps that are shared across the team, shared app connections, or in a team/company account will not be migrated.
Alternatively, you can pass the --account
flag, (i.e. zapier migrate 1.0.0 1.0.1 --account=account@example.com
). This will migrate all Zaps owned by the user, Private & Shared, within all accounts for which the specified user is a member.
The --account
flag should be used cautiously as it can break shared Zaps for other users in Team or Enterprise accounts.
You cannot pass both PERCENT
and --user
or --account
.
You cannot pass both --user
and --account
.
Arguments
Usage: zapier migrate FROMVERSION TOVERSION [PERCENT]
Start a migration to move users between different versions of your integration. You may also "revert" by simply swapping the from/to verion strings in the command line arguments (i.e. zapier migrate 1.0.1 1.0.0
).
Only use this command to migrate users between non-breaking versions, use zapier deprecate
if you have breaking changes!
Migration time varies based on the number of affected Zaps. Be patient and check zapier jobs
to track the status. Or use zapier history
if you want to see older jobs.
Since a migration is only for non-breaking changes, users are not emailed about the update/migration. It will be a transparent process for them.
We recommend migrating a small subset of users first, via the percent argument, then watching error logs of the new version for any sort of odd behavior. When you feel confident there are no bugs, go ahead and migrate everyone. If you see unexpected errors, you can revert.
You can migrate a specific user's Zaps by using --user
(i.e. zapier migrate 1.0.0 1.0.1 --user=user@example.com
). This will migrate Zaps that are private for that user. Zaps that are
in a team/company account
+will not be migrated.
Alternatively, you can pass the --account
flag, (i.e. zapier migrate 1.0.0 1.0.1 --account=account@example.com
). This will migrate all Zaps owned by the user, Private & Shared, within all accounts for which the specified user is a member.
The --account
flag should be used cautiously as it can break shared Zaps for other users in Team or Enterprise accounts.
You cannot pass both PERCENT
and --user
or --account
.
You cannot pass both --user
and --account
.
Arguments
fromVersion
| The version FROM which to migrate users.toVersion
| The version TO which to migrate users.percent
| Percentage (between 1 and 100) of users to migrate.