docs: various updates to migration docs from forum questions

astro/src/content/blog/how-to-migrate-from-azure-ad-b2c.mdx

@@ -1,5 +1,5 @@
 ---
-publish_date: 2022-10-10 
+publish_date: 2022-10-10
 title: How to migrate from Azure AD B2C
 description: How can you migrate your user data away from Azure AD B2C?
 authors: Dan Moore
@@ -52,7 +52,7 @@ These include:
 * SMS pricing is expensive relative to other options.
 * You can't backup or export all user data, notably password hashes.
 
-These limitations can be acceptable initially, but eventually you may need a feature not provided by Azure AD B2C, such as a unique login provider or the OAuth device grant. Or perhaps you need fine-grained control over the user interface your customers will see. 
+These limitations can be acceptable initially, but eventually you may need a feature not provided by Azure AD B2C, such as a unique login provider or the OAuth device grant. Or perhaps you need fine-grained control over the user interface your customers will see.
 
 For whatever reason, you may decide to move your customer and user data from Azure AD B2C. Let's take a look at how you might do so, but first, let's talk about why you should say put.
 
@@ -74,7 +74,7 @@ This unfortunate choice is required because Azure AD B2C does not let you export
 
 <Aside type="note">This blog post gives general guidance on migration off of Azure AD B2C to any other auth provider. If you are looking for step by step instructions on how to migrate from Azure AD B2C to FusionAuth, please review our [Azure AD B2C migration guide](/docs/lifecycle/migrate-users/bulk/azureadb2c).</Aside>
 
-If the answer is yes, you are okay forcing users to reset their password, you can perform a point-in-time bulk migration. 
+If the answer is yes, you are okay forcing users to reset their password, you can perform a point-in-time bulk migration.
 
 If the answer is no, you are looking at a more complicated scenario, a phased, drip or "slow" migration. With this, users are migrated one at a time as they log in.
 
@@ -145,7 +145,7 @@ In subsequent logins, the original Azure AD B2C system is never consulted, as be
 The basic steps of a slow migration are:
 
 * Set up the new system. Make sure you map all functionality and data from Azure AD B2C to the new system.
-* Determine what constitutes "done" for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see [more details on how to calculate that](/docs/lifecycle/migrate-users/general-migration#migration-timeline).
+* Determine what constitutes "done" for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see [more details on how to calculate that](/docs/lifecycle/migrate-users#migration-timeline).
 * Set up a way for the new system to present user credentials to Azure AD B2C for an authentication event. The exact method will depend on new system features. This can be done with an Azure Function; see [this document](/docs/lifecycle/migrate-users/bulk/azureadb2c#configuring-the-azure-function) for an example which works with FusionAuth.
 * Create configuration in the new auth system corresponding to the configuration in Azure AD B2C. You should also customize the user interface, messages, MFA methods and any other Azure AD B2C specific settings that are relevant.
 * Update your applications to point to the new auth system.

astro/src/content/blog/how-to-migrate-from-cognito.mdx

@@ -1,5 +1,5 @@
 ---
-publish_date: 2022-02-07 
+publish_date: 2022-02-07
 title: How to migrate from Amazon Cognito
 description: How can you migrate away from Amazon Cognito?
 authors: Dan Moore
@@ -22,7 +22,7 @@ At FusionAuth, we talk to potential customers who are interested in migrating aw
 
 This blog post will explain why and how you might choose to migrate from Amazon Cognito to another solution. This is more complicated than it might seem because you cannot access the password hashes of users in Cognito, which has impacts the way you can migrate their authentication experience.
 
-## Weaknesses of Amazon Cognito 
+## Weaknesses of Amazon Cognito
 
 While [Amazon Cognito](https://aws.amazon.com/cognito/) is a low cost auth service and a far better choice than rolling your own auth solution, it has some downsides. These include:
 
@@ -38,7 +38,7 @@ While [Amazon Cognito](https://aws.amazon.com/cognito/) is a low cost auth servi
 * SAML accounts are expensive after you grow beyond the free tier.
 * Possibly most concerning, Amazon Cognito has been relatively static and has received few recent improvements.
 
-These limitations may be acceptable initially, but eventually you may need a feature not provided by Amazon Cognito, such as a unique login provider or the OAuth device grant. Or perhaps you want more control over the user interface your customers will see. 
+These limitations may be acceptable initially, but eventually you may need a feature not provided by Amazon Cognito, such as a unique login provider or the OAuth device grant. Or perhaps you want more control over the user interface your customers will see.
 
 For whatever reason, you may decide you need to move your customer and user data from Amazon Cognito. Let's take a look at how you might do so.
 
@@ -58,11 +58,11 @@ After you have decided to migrate from Amazon Cognito, the first decision you'll
 This blog post gives general guidance on migration off of Amazon Cognito to any other auth provider. If you are looking for step by step instructions on how to migrate from Amazon Cognito to FusionAuth, please review our [Amazon Cognito migration guide](/docs/lifecycle/migrate-users/bulk/cognito).
 </Aside>
 
-If the answer is yes, then you have the option of a point-in-time bulk migration. 
+If the answer is yes, then you have the option of a point-in-time bulk migration.
 
 If the answer is no, then you will be instead looking at a phased or "slow" migration, where users are migrated one at a time as they log in.
 
-In general, the more users you have and the less they need your application, the less you'll want to impact them by forcing a password reset. However, a slow migration is more complex operationally (some users will exist in the new system, some in Cognito). 
+In general, the more users you have and the less they need your application, the less you'll want to impact them by forcing a password reset. However, a slow migration is more complex operationally (some users will exist in the new system, some in Cognito).
 
 If you aren't sure, you have the option of segmenting your user base and migrating one section. This will allow you to see what effect requiring a password change has on engagement and conversion.
 
@@ -121,15 +121,15 @@ In subsequent logins, the original Cognito system is never consulted.
 The basic steps of a slow migration are:
 
 * Set up the new system. Make sure you map all functionality and data from Cognito to the new system.
-* Determine what constitutes "done" for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see [more details on how to calculate that](/docs/lifecycle/migrate-users/general-migration#migration-timeline).
+* Determine what constitutes "done" for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see [more details on how to calculate that](/docs/lifecycle/migrate-users#migration-timeline).
 * Set up a way for the new system to present user credentials to Amazon Cognito for an authentication event. The exact method will depend on new system features. This can be done with an AWS Lambda; see [this document](/docs/lifecycle/migrate-users/bulk/cognito#set-up-aws) for an example which works with FusionAuth.
 * Create configuration in the new auth system corresponding to the client configuration previously set up in Amazon Cognito. You should also customize the user interface, messages, MFA methods and any other Cognito specific settings that are relevant.
 * Update your custom, COTS or OSS applications to point to the new auth system.
 * Wait, running reports periodically to determine if you've migrated enough users to shut down the slow migration.
 * Decide what to do with unmigrated users. Options include abandoning them, a bulk migration, or contacting them to encourage a sign-in.
 * Eventually, [delete the Cognito user pools](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cognito-idp/delete-user-pool.html) to ensure that all of your users are authenticating against the new system. You could also use a lambda to disable logins.
 
-Slow migrations have less impact on your users, but more impact on your systems and employees and take more time. For instance, if a customer service representative needs to reset a password, they will have to determine if the user has been migrated to the new system or not before they can process the request. 
+Slow migrations have less impact on your users, but more impact on your systems and employees and take more time. For instance, if a customer service representative needs to reset a password, they will have to determine if the user has been migrated to the new system or not before they can process the request.
 
 ## Conclusion
 

astro/src/content/blog/how-to-migrate-from-firebase.mdx

@@ -1,5 +1,5 @@
 ---
-publish_date: 2022-05-25 
+publish_date: 2022-05-25
 title: How to migrate your user data from Google Firebase
 description: How can you migrate user data such as password hashes and social logins away from Google Firebase?
 authors: Dan Moore
@@ -48,13 +48,13 @@ Firebase has strengths as well as weaknesses, and if your application depends on
 
 For example, if the customization is acceptable and you are using lots of Firebase features, migration doesn't make sense. The fact that Firebase is serverless makes it easy to "set and forget" and allows you to focus on other aspects of your application. You know, the features your users want.
 
-If you need Firebase's messaging, analytics or the Cloud Firestore NoSQL database and are not willing to look at alternatives, migration also won't make sense. A standalone auth provider won't provide the breadth of functionality, and you may not want to piece together replacements for everything Firebase offers. 
+If you need Firebase's messaging, analytics or the Cloud Firestore NoSQL database and are not willing to look at alternatives, migration also won't make sense. A standalone auth provider won't provide the breadth of functionality, and you may not want to piece together replacements for everything Firebase offers.
 
 ## How to migrate
 
 If, however, you have decided to migrate from Firebase, the first decision you'll need to make is: "With what will I replace the other Firebase functionality I depend on?"
 
-One option is to leave parts of your application running on Firebase. 
+One option is to leave parts of your application running on Firebase.
 
 Another is to migrate it all to an environment where you have more control. What makes sense here depends on what other Firebase functionality you use.
 
@@ -73,7 +73,7 @@ The basic steps of a bulk migration are:
 * Set up the new auth system. Make sure you map user functionality and data from Firebase to the new system. Ensure the new system supports the [modified scrypt hashing algorithm](https://firebase.google.com/docs/reference/admin/java/reference/com/google/firebase/auth/hash/Scrypt) used by Firebase.
 * Export your user data from Firebase. You can do this with the Firebase CLI: `firebase auth:export users.json --format=JSON --project your_project_id`.
 * Massage the exported user data into a format acceptable to your new provider, using whatever data transformation tools you are comfortable with.
-* Upload the user data to the new provider. 
+* Upload the user data to the new provider.
 * Create configuration in the new auth system corresponding to the applications previously set up in Firebase. You should also customize the user interface, messages, MFA methods and any other specific relevant settings.
 * Update your custom, COTS or OSS applications to point to the new auth system.
 * Disable the sign-in methods in your Firebase application to ensure that all of your users are authenticating against the new system.
@@ -115,7 +115,7 @@ After the initial login, Firebase is no longer the system of record for that use
 The basic steps of a slow migration are:
 
 * Set up the new auth system. Make sure you map all user functionality and data from Firebase to the new system.
-* Determine what constitutes "done" for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see [more details on how to calculate that](/docs/lifecycle/migrate-users/general-migration#migration-timeline).
+* Determine what constitutes "done" for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see [more details on how to calculate that](/docs/lifecycle/migrate-users#migration-timeline).
 * Set up a way for the new system to present user credentials to Firebase during an authentication event. The exact method will depend on new system features, with FusionAuth you use [Connectors](/docs/lifecycle/migrate-users/connectors/). On the Firebase side, it can be done with an API call; see [this Firebase documentation](https://firebase.google.com/docs/reference/rest/auth#section-sign-in-email-password) for more.
 * Create configuration in the new auth system corresponding to the applications previously set up in Firebase. You should also customize the user interface, messages, MFA methods and any other settings that are relevant.
 * Update your custom, COTS or OSS applications to point to the new auth system.
@@ -125,7 +125,7 @@ The basic steps of a slow migration are:
 
 Slow migrations have less impact on your users, but more impact on your systems and employees and take more time.
 
-For instance, if a customer service representative needs to reset a password, they will have to determine if the user has been migrated to the new system or not before they can process the request. 
+For instance, if a customer service representative needs to reset a password, they will have to determine if the user has been migrated to the new system or not before they can process the request.
 
 ## Conclusion
 

astro/src/content/docs/apis/_import-users-request-body.mdx

@@ -8,7 +8,7 @@ import RemovedSince from 'src/components/api/RemovedSince.astro';
 import ScrollRef from 'src/components/ScrollRef.astro';
 import UserDataEmailFieldImportRequest from 'src/content/docs/apis/_user-data-email-field-import-request.mdx';
 
-You must provide either the **email** or the **username** field for each User. This will be used to authenticate the User and is also the User's unique identifier. These fields are marked as optional below, but you must provide one of them.
+You must provide either the **email** or the **username** field for each User. This will be used to authenticate the User and is also the User's unique identifier. These fields are marked as optional below, but you must provide one of them. The **password** field (plaintext or hash) is also required.
 
 #### Request Body
 

astro/src/content/docs/apis/users.mdx

@@ -339,7 +339,7 @@ The response for this API contains the information for the User that was reactiv
 
 ## Import Users
 
-This API is used to bulk import multiple Users into FusionAuth. Each User must have at least an **email** or a **username**. This request is useful for migrating data from an existing database into FusionAuth. Additionally, you can provide an Id for each User inside the JSON User object of the request body. When using this API you should import with batches of less than 10,000 users per request. After completing an import you should [reindex of the Elasticsearch database](/docs/lifecycle/manage-users/search/search#reindexing-elasticsearch) as well.
+This API is used to bulk import multiple Users into FusionAuth. Each User must have at least an **email** or a **username**, and a **password** (plaintext or hash). If you don't have the User's password, you can set this field to a long random string and require the User to reset their password at their next login. This request is useful for migrating data from an existing database into FusionAuth. Additionally, you can provide an Id for each User inside the JSON User object of the request body. When using this API you should import with batches of less than 10,000 users per request. After completing an import you should [reindex of the Elasticsearch database](/docs/lifecycle/manage-users/search/search#reindexing-elasticsearch) as well.
 
 ### Request
 

astro/src/content/docs/lifecycle/authenticate-users/_mfa-migration.mdx

@@ -2,14 +2,14 @@ import InlineField from 'src/components/InlineField.astro';
 
 Users with supported multi-factor methods can be migrated.
 By using the [Users API](/docs/apis/users) and updating the <InlineField>twoFactor</InlineField> attributes of each user, you can migrate any of the supported MFA methods.
-You can use this with a bulk import or a slow migration.
+You can use this with a bulk import or a gradual migration.
 
 ```json title="twoFactor object when migrating email MFA methods"
 "twoFactor": {
   "methods": [{
     "method": "email",
     "email": "[email protected]"
-  }, 
+  },
   {
     "method": "email",
     "email": "[email protected]"