What's the easiest way to migrate 500 users from one platform to another?

Migrating 500 user accounts is a common scenario that sits in an interesting niche: it's beyond a trivial manual job, but not yet at the scale requiring fully automated, complex tooling. The "easiest" method balances minimal custom code with robust validation.

I recently executed this for a SaaS analytics platform migration, moving from a legacy user store in PostgreSQL to a new system in AWS Cognito and a DynamoDB profile table. The key was treating it as a simple, idempotent ETL batch job.

**Data-Migration Approach**
The core logic was a Spark job (though a Python script would suffice) that performed a sequenced extract, transform, and load.

1. **Extract:** Read from the source PostgreSQL `users` table and related `user_profile` table.
2. **Transform:** Map fields, hash passwords for the new system (requiring a one-time reset flag), and generate compatible JSON structures. De-duplication on email was handled here.
3. **Load:** Write to two sinks:
* A CSV formatted for AWS Cognito's bulk import.
* A JSONL file for the DynamoDB profiles, later loaded using a batch write.

The job was designed to be idempotent; re-running it would not create duplicates.

**Example Spark Snippet for Mapping:**
```python
# Pseudocode for the transformation logic
df_transformed = df_source.select(
col("email").alias("cognito:email"),
col("id").alias("user_id"),
hash_password(col("legacy_hash")).alias("temporary_password"),
lit("TRUE").alias("reset_required"),
from_unixtime(col("created_at")).alias("profile_created_date")
)
```

**Cutover Plan**
1. **Dry Run:** Execute the job in write-to-file mode only, generating the output CSVs/JSONs. Validate record counts and sample data.
2. **Pre-load:** Bulk import users into Cognito in a `FORCE_CHANGE_PASSWORD` state. Load profiles into DynamoDB. This was done during a maintenance window.
3. **Communication:** Each user received a system-generated temporary password via email, forcing a first-login reset. This handled the password migration securely.
4. **Parallel Verification:** For a 48-hour period, the old system remained readable. We verified login success and data completeness for a sample of users.
5. **Sunset:** Old user write APIs were disabled; all new traffic routed to the new auth service.

**How Long It Actually Took**
* **Development & Testing:** 3 days (including building the validation scripts).
* **Dry Run & Validation:** 1 day.
* **Actual Cutover Window:** 2 hours (mostly for the bulk import, pre-loading DynamoDB, and final sanity checks).
* **Parallel Run Period:** 2 days.

The total active effort was about one week. The most time-consuming part was not the data movement, but defining the field mappings and coordinating the cutover communication. Using the target platform's (Cognito) bulk import feature was the major timesaver, avoiding the need to build hundreds of individual API calls.