How to export your data from AWS Amplify

Export data from AWS Amplify in four parts, and know what stays behind

A team leaving Amplify has to export four things separately: the data in DynamoDB tables, the user attributes in Cognito, the objects in S3 buckets, and the TypeScript and CDK code that defines the backend. No single export covers the whole backend. A DynamoDB export does not carry Cognito users, an S3 copy does not carry table rows, and the backend definition lives in your source repository and must be rewritten for the new platform. Plan each part as its own workstream with an owner, a validation step and a cutover date. Start by listing every table, user pool, bucket and Amplify environment, including development and staging, because teams often find resources they forgot they created.

Cognito is the part most teams underestimate. Cognito passwords cannot be listed. A ListUsers call returns user attributes such as usernames, email addresses and verification status, but it does not return password material that you can carry into Supabase or Appwrite. Confirm in the current AWS documentation exactly what the call returns and which IAM permissions it needs in your account. Decide before the migration whether users will reset passwords on first sign-in, receive an invitation, or move through an import flow that the target platform supports. Also review the user pool's custom attributes, since each one needs a place in the new auth model.

For DynamoDB, the export to S3 requires point-in-time recovery to be enabled on each table, so check that setting well before your planned window. Confirm the current export formats with AWS (DynamoDB JSON and Ion are the options to verify), along with size limits, throughput considerations and any effect on live traffic. This page does not list AWS quotas, so verify them against AWS documentation for your region before you commit to a date. Treat the exported files as raw input. They still need reshaping into Postgres tables, and the migration guide covers that step.

Which export path each AWS Amplify data type uses

This table maps each part of an Amplify backend to the export path that moves it out, the output format it produces and the prerequisites to confirm before you start. Read it row by row against your own Amplify app, since a single Gen 2 backend usually spans all four data types. The main takeaway is that DynamoDB data needs point-in-time recovery enabled before an export, Cognito passwords cannot be exported at all, and the backend code must be kept as source control history for the rebuild.

Data type	Export method	Output format	Limits or prerequisites to confirm
DynamoDB tables	Full table export to an S3 bucket through the DynamoDB export feature	DynamoDB JSON or Amazon Ion	Confirm point-in-time recovery is enabled on each table, the S3 bucket and IAM permissions, and the export's cost and duration in AWS documentation
Cognito user attributes	Read user profiles page by page through the ListUsers API	JSON records you write yourself	Passwords are not returned, so every user needs a reset or a hash-based import path; confirm current API quotas and attribute limits
S3 objects	Copy objects with the S3 API or a sync tool into the new bucket or storage service	Original object files and metadata	Confirm bucket permissions, object versioning state, storage class and transfer charges for your data volume
Backend TypeScript and CDK code	Source control export from your Git repository, including the Amplify backend definition	Source files that you rebuild as new schema, functions and policies	Confirm the repository holds the full backend definition, environment variables and secrets are stored elsewhere, and the AppSync resolvers and Lambda code are included

Choosing DynamoDB JSON or Ion for the export

DynamoDB JSON is the typed representation DynamoDB uses for attribute values. Every value carries a type descriptor, so a string sits under S, a number under N (stored as a string), and nested maps and lists sit under M and L. Each line of the export wraps one item in an Item object, which keeps the file readable without a DynamoDB connection but leaves it far from the plain rows a Postgres table or an Appwrite document expects.

File shape: each line holds an Item object whose attributes are wrapped in type descriptors, such as {"S": "u_102"}.
Type wrappers: every scalar must be unwrapped before it becomes a column value, and numeric values must be converted from strings.
Nested maps and lists: M and L nest to any depth, so document-style items need flattening into child tables or a jsonb column.
Downstream tooling: many scripts that already understand DynamoDB's typed format read this form directly, which makes it the default for ad hoc loaders.

Confirm that your chosen loader strips the Item wrapper and the type descriptors, then test it on a sample export before running the full dataset.

Amazon Ion is a richer data format that is a superset of JSON. It adds native types such as timestamps, decimals and symbols, and it can be written as text or as a compact binary encoding. Those types keep dates and exact numbers from arriving as strings, which reduces some conversion work. The same reshaping still applies, because nested structures must still be mapped to relational columns or documents, and fewer general-purpose loaders read Ion than read JSON.

File shape: text Ion resembles JSON with richer type annotations, while binary Ion is compact but not human-readable.
Type fidelity: timestamps and decimals keep their types, so date and currency columns need less casting after import.
Tooling support: fewer general-purpose tools accept Ion directly, so a Postgres COPY or an Appwrite import script will often need a conversion stage first.
Conversion risk: converting binary Ion to JSON or CSV adds a stage that needs its own tests and error handling.
Nested attributes: lists and structs still need flattening decisions, including which fields become child rows and which stay in document fields.

Confirm which encoding your export produces, and check whether your loader reads it without an extra conversion step.

The format matters less than the loader that will read it. Start by listing the destination import path, whether that is a Postgres load into Supabase, a schema-mapping script, or the Appwrite migration tooling, and find out which input formats each accepts. The format that the loader reads directly removes a conversion stage, and every removed stage removes a point where errors can enter the data.

Start from the destination: the loader or import path, not the export, sets the format that is practical to use.
Count conversion stages: a format the loader reads directly saves a step that would otherwise need its own code and testing.
Check type fidelity: where timestamps, decimals or binary attributes matter, compare a sample row before and after import.
Plan nested attributes: either format still requires decisions about which nested fields become relational columns and which stay as documents or jsonb.
Run a sample partition: export one partition or a small table through the full pipeline before committing to the complete export.

Ask the team that will own the import which format they have tested, and record that decision alongside the reshaping rules for each table.

What does not export from Amplify and how teams work around it

Most of an Amplify backend moves as data or code, but several parts never leave AWS in a usable form. Each card below names one item, the workaround teams use, and who in the organization has to act before cutover.

Cognito password hashes

Cognito does not let you list or export password hashes, so the ListUsers call returns profile attributes but no credentials. Teams either force a password reset for every user or move accounts on first login, verifying the password against Cognito through a temporary bridge before storing the new credential in the target auth system. Security and identity owners should decide which path fits their policy, and product owners should plan the sign-in messaging that users will see.

AppSync resolver logic

AppSync resolvers, including their VTL or JavaScript mapping logic and authorization rules, are not stored as data you can copy into Postgres or Appwrite. Engineers have to read each resolver, record which checks it performs, and rewrite them as database policies, server functions or API code. Ask the application team to list every resolver and its authorization rule before estimating the rewrite.

Amplify-generated GraphQL schema

The GraphQL schema that Amplify Gen 2 generates from your TypeScript data definition is build output, not a file your team edits directly. Its table names, relationship keys and generated client code must be rewritten as explicit tables, foreign keys and client calls on the target platform. Frontend developers should check every query and mutation against the new schema, since generated client types will no longer compile after the switch.

Lambda runtime state and secrets

Lambda environment variables, secrets held in parameter or secret stores, and any warm in-memory state do not move with the data. Operators must re-enter each secret into the target platform's secret handling or an external secrets manager, then rotate any credential that was exposed to the old environment. Confirm the inventory of function configuration with the cloud team before the export starts.

Hosting configuration and custom domains

Amplify Hosting holds build settings, environment variables, redirect rules, branch mappings and custom domain certificates. None of these appear in the data export, so the frontend team must recreate the build pipeline on the new host and move DNS records with a planned cutover window. Ask the hosting owner to export the Amplify app settings and confirm which domains point to Amplify before changing any records.

Cognito triggers and identity pools

Cognito triggers such as pre-signup, post-confirmation and custom message functions, along with identity pool role mappings, run inside AWS and have no direct equivalent in the target platform. Each trigger's business logic must be ported to an auth hook or server function, and identity pool roles must be replaced with the new platform's permission model. Security and identity teams should review each trigger to confirm it still enforces the same checks after the move.

Export data from AWS Amplify in a sequence that can be verified

This sequence freezes a single point in time, copies each data source out of Amplify, and records a check for every output so the team can prove the export is complete before anything is decommissioned. Each step names the check that closes it and the person who signs off.

Freeze the export date and inventory resources
Choose one export date and tell the team that writes to the Amplify backend will stop or be paused for the cutover window, since later changes will not appear in a snapshot taken from an earlier point. Build an inventory from the Amplify project: every DynamoDB table generated by the Gen 2 data resource, every S3 bucket used for storage, and every Cognito user pool, with its ID and region. The engineering lead signs off on the inventory, and the sign-off is complete when the list is saved in the migration repository with a named owner for each resource.
Confirm point-in-time recovery on each table
For each DynamoDB table, confirm that point-in-time recovery is enabled in the AWS console or with the AWS CLI, because the native export to S3 depends on it. Record the table name, the enabled state and the recovery point used for the export. Check that the table's recovery settings match the freeze time so the export reflects the agreed snapshot. The platform owner signs off once every table in the inventory shows point-in-time recovery enabled and the recorded recovery time falls within the freeze window.
Run the DynamoDB exports to S3
Start a full table export to a dedicated S3 bucket for each table, choosing DynamoDB JSON or Amazon Ion as the output format and noting the choice in the runbook, since the reshaping scripts must read the same format. Keep each export in its own prefix so later steps can match files to tables. Wait for every export job to report completion, then record the export ARN, item count reported by the job and the S3 prefix. The data engineer signs off when every job reports a completed status and each prefix contains a manifest file.
Export Cognito users with ListUsers
Use the Cognito ListUsers API for each user pool to write user attributes, usernames, status and creation dates to a file, paginating until no further token is returned. Passwords cannot be listed through this API, so the export carries identity data only, and users will need a reset or a hash migration path on the new platform. Save the output alongside the inventory and note which users are disabled or unconfirmed. The identity owner signs off once the record count from the export matches the user count reported in the Cognito console for that pool.
Copy S3 objects to the target store
Copy every object from the Amplify storage buckets to a staging location, preserving key names and prefixes so that file paths in the database still resolve after the move. Generate an object list with sizes and, where the bucket tooling supports it, stored checksums for each key. Keep the copy log with the source and destination counts. The storage owner signs off when the object count and total byte size in the destination match the source listing and every key appears in the log without errors.
Export the backend code from the repository
Archive the Git repository at the exact commit deployed to the freeze environment, including the Amplify Gen 2 TypeScript backend definition, the CDK constructs, schema files, function handlers and any custom resolvers. Record the commit hash and tag the archive so the team can see which definitions produced the exported data. Confirm that the archive builds locally without AWS credentials for the parts that do not depend on deployed resources. The lead developer signs off when the commit hash, archive checksum and a clean build log are stored with the inventory.
Verify and record every output
Verify each output against its source: compare record counts for each DynamoDB export with the item count in the export manifest and with a sampled query, compare user counts from the Cognito file with the pool, compare S3 object counts and byte totals with the bucket listing, and compare checksums for a defined sample or for all files where possible. Record each result in a single verification log with the date, the check, the expected value, the actual value and the outcome. A failed check reopens the matching step. The migration lead signs off only when every line in the log shows a pass, and the log is stored with the inventory and the repository archive.

How to verify that the export is complete before you cancel anything

Reconcile every source against its export before you cancel anything. For DynamoDB, compare the item count of each table with the record count in the export manifest that accompanies the S3 export, and sample a set of items to confirm attribute types survived the conversion from DynamoDB JSON or Ion. For Cognito, count the users returned by ListUsers across the full pagination and compare that total with the user count shown in the Cognito console for the same user pool. Those two numbers should match, or you should be able to explain every difference, such as accounts disabled or unconfirmed in one view but not the other. For S3, compare object counts and total bytes per bucket with the copy you made, and check a sample of files by checksum rather than by size alone. Confirm the counts in writing before you move on, because the Cognito password hashes are not in the export, so user counts are the only check you can run on the identity side.

Confirm the code side as well. Check out the backend TypeScript and CDK code from the repository at the revision that produced the production stack, then run a synthesis step in a clean environment and confirm the template matches what is deployed. This shows that the data you exported corresponds to the schema the code describes, and it gives you a record of the resource names and key schemas your migration must reproduce. Keep the source environment running and read-only until a restore test on the destination succeeds: load the exported data into a non-production target, run your application's read paths against it, and sign in with a test account that exists only in the destination. Only then should you plan the cutover, and only then should you schedule the retirement of Amplify resources. Retain the export logs, manifests, count reports and restore test results together as evidence, so that anyone who later asks whether data was lost can see what was checked and when.

Which backend TypeScript and CDK code needs rewriting after the export

The Amplify Gen 2 definition is the code you rewrite, and most of it does not carry over as is. In a Gen 2 project, the data models, authorization rules, functions and triggers are declared in TypeScript and synthesized through the AWS CDK, so the export gives you the data but not the logic that shaped it. Start by inventory: list every file under the backend folder that defines a schema, auth configuration, function or trigger, and every CDK construct it references. Do this with the engineers who wrote and still maintain that code, because the schema and its authorization rules often encode product decisions that nobody has written down elsewhere.

Map each part to its destination before any rewrite begins. Data models become Postgres tables in self-hosted Supabase or collections in Appwrite, and the field types, relationships and indexes need to be rebuilt in the destination's own terms. Authorization rules are the highest-risk item: owner and group rules defined in the schema must become row-level security policies in Supabase or permissions on collections and documents in Appwrite. Functions move to the destination's runtime, which is Supabase Edge Functions on Deno or Appwrite Functions running on Open Runtimes, and every trigger, such as a Cognito post-confirmation hook or a DynamoDB stream handler, has to be re-implemented as a database trigger, a webhook or a scheduled job. Confirm each mapping against the destination's current documentation before work starts, since the Appwrite Functions and Supabase Edge Runtime APIs differ from Lambda and AppSync in their details.

Treat the rewrite as a scoped deliverable with written acceptance tests. For each authorization rule, write a test that proves a user can read or change only the records the Amplify rule allowed, and run it against the destination before cutover. Keep the original CDK code in version control so you can compare behavior during parallel running, and record which Amplify features have no direct equivalent, such as AppSync subscriptions or custom resolvers, so the team can decide how to replace them. Ask any implementation partner to deliver this mapping as a document with sign-off from your own engineers, not only as code.

What to plan before the AWS Amplify contract ends

An Amplify exit runs on AWS account decisions as much as on code. The cards below cover the decisions and checks that sit before any export starts, so the data copy, user migration and restore test can run against a fixed plan.

Set the cutover window

Decide when the Amplify app goes read-only, when writes move to the new backend, and how long both stay available for rollback. Confirm with product owners how many users will be affected during the switch and whether mobile clients have a minimum version that must be forced. Agree the window in writing before the first export, so DynamoDB snapshots are taken at a known point in time and any writes after that point are captured in a delta plan.

Confirm the account owner and billing

Confirm with AWS and your finance team which account owns the Amplify app, DynamoDB tables, Cognito user pool, S3 buckets and Lambda functions, and who receives the invoices after termination. Keep the account open long enough to run exports and access logs, because deleting resources removes the source you need for verification. Ask AWS support what retention applies to deleted resources in your account, and record the answer.

Plan Cognito user communication

Cognito does not let you list password hashes, so user records move without passwords and users must reset them or sign in through a migration flow. Decide which path applies: a forced reset email, a lazy migration that verifies credentials on first login, or a social sign-in bridge. Confirm with the security team how reset emails are sent, who answers support requests, and how users with unverified emails are handled before the cutover.

Reserve time for a restore test

Before deleting anything, restore the exported DynamoDB data and S3 objects into the destination environment and check row counts, key shapes and a sample of files against the source. Ask the team who will run the test, which application paths they will exercise, and who signs off. Because the test shapes the schedule, book it before the contract end date rather than after the cutover.

Document residency for the destination

Record where the data lives today and where the new backend will run. Amplify data sits in the AWS region chosen for the app, while a self-hosted Supabase or Appwrite stack runs wherever you deploy it. Confirm with your data protection officer which regions and countries are approved, and whether backups, logs and the S3 export bucket are in scope. For Supabase Cloud comparisons, note that each project is hosted in one main region chosen from 17 AWS regions, so location is fixed early.

Set a deletion date for copies

Exported DynamoDB files, S3 copies and user lists contain personal data and should not outlive their purpose. Once the destination is verified and users have moved, set a dated deletion for every intermediate copy, including the staging bucket and any local files on laptops. Confirm with security and legal whether the source Amplify resources can be deleted at the same time, and record who approved the deletion and when it ran.

Questions teams ask before exporting data from AWS Amplify

How much effort does exporting data from Amplify take?

The export itself is mechanical, and the effort comes from how much there is to move and how it must be reshaped. The main drivers are the number of DynamoDB tables, the record volume in each, the number of Cognito users, the custom resolvers and access rules tied to the current schema, and the number of environments such as development, staging and production, since each holds its own tables, buckets and user pools. DynamoDB exports can be written in DynamoDB JSON or Amazon Ion, so the format you choose affects how much parsing your import scripts need. A team with a small, single-table model and one environment has far less to do than a team with many models, custom resolvers and several stages. Ask any provider for an inventory of tables, users, buckets and environments before agreeing a scope.

Can our own engineers run the Amplify export without help?

Yes, for the export steps themselves. Engineers with the right AWS access can start a DynamoDB export to S3, call Cognito ListUsers to pull user attributes, and copy S3 objects to the new storage location, provided their IAM permissions allow it. The harder work is reshaping the data. Amplify data models often store related records in ways that do not map directly onto Postgres tables or Appwrite collections, so someone must design the new schema, write transformation code and check the results. Rewriting authorization is the other hard part, because access rules defined in AppSync and Cognito groups must be recreated in the target platform and tested with real user roles. Many teams keep the export in-house and bring in outside help for the reshaping and access rules.

How long does an Amplify data export take?

No duration can be stated responsibly until the inventory is complete, so treat any timeline as provisional until the scope is written. The schedule depends on data volume, the number of tables and users, how many environments need moving, and the cutover window your business can accept. Cutover usually requires a period when writes are paused or synchronized so the final export matches live data, and that window is often the most sensitive part of the plan. Reshaping and validation generally take longer than the export itself, and each round of test imports adds time. Parallel work on the schema, the auth migration and the code rewrite can shorten the calendar but needs clear ownership. Ask for a plan with named milestones, a rehearsal in a non-production environment and an agreed cutover checkpoint.

Can Amplify passwords be exported with user accounts?

No. Cognito's ListUsers call returns user attributes such as email, username and account status, but it does not return password hashes, so passwords cannot be copied out of the user pool. The migration therefore needs a different route. Common approaches include forcing a password reset on first sign-in, sending invitations to set a new password, or running a login-time migration that checks the old credentials against Cognito and creates the account in the new platform once they succeed. Each approach affects user experience and how long the old user pool must stay available. Confirm which options the target platform supports, and plan user communication before cutover. Also map the attributes, groups and custom claims your application depends on, since they must carry over into the new auth model.

Must point-in-time recovery be enabled before a DynamoDB export?

Yes. DynamoDB exports to S3 require point-in-time recovery to be enabled on each table, because the export reads from a snapshot taken within the recovery history. Enabling it adds a recurring charge tied to the size of the stored table data, so cost depends on table size and how many tables you include. Check the current DynamoDB pricing for your region, since rates can change. The setting also keeps continuous backups for a retention window, which can help if a bad import needs to be reversed. Enable it in each environment you export, and decide with your team whether to keep it on after cutover. Confirm the table list and recovery settings during planning so the export is not blocked late in the project.

What does our team need to provide for the export?

Access and knowledge are the main requirements. Provide AWS credentials or a role that can run DynamoDB exports, read the Cognito user pools, and list and copy S3 buckets, scoped to the environments in scope. Someone who owns the data model must explain relationships, access patterns and records that are soft-deleted or derived. The team also needs the backend TypeScript and CDK code in version control, along with a list of custom resolvers and Lambda functions. A product owner should approve the cutover window and user communication, and a named reviewer should sign off on samples of migrated data. Finally, agree who will operate the target environment, its secrets and its backups after the work ends, since self-hosted platforms need an accountable operator.

What does a DeployOpen scope cover for an Amplify export?

A DeployOpen engagement is fixed-scope, so deliverables and timelines are agreed in writing before work starts. An illustrative scope for this export could include an inventory of tables, user pools, buckets and environments, DynamoDB exports with point-in-time recovery configured, transformation scripts that reshape records for the target database, a user migration plan that fits the password constraints, S3 object copies with validation, and rewritten authorization rules tested against real roles. It can also cover the target deployment in your own infrastructure, backup setup, cutover support and handover documentation. Ongoing support and upgrades are available as a retainer. DeployOpen does not publish prices, and a quote follows from the written scope, so use the inventory to request line items that match your environments.

Which code must be rewritten after the data moves?

The Amplify backend definition is usually the largest rewrite. The TypeScript and AWS CDK code that defines the data schema, auth rules, functions and storage buckets has no direct equivalent in the target platform, so each part must be rebuilt in that platform's own configuration. AppSync resolvers become queries, policies or server-side functions, and Lambda handlers must move to the new function runtime with their environment variables and triggers. Frontend code that calls Amplify client libraries for auth, data and storage also changes, because it must use the new SDK. Expect to rewrite the auth flow, including sign-in, sign-up, password reset and session handling. Keep the CDK code under version control during migration so you can compare behavior between the old and new stacks, and list every trigger or scheduled job that depends on DynamoDB streams or S3 events.

How DeployOpen scopes and delivers an Amplify data exit

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Amplify data exit, we scope the DynamoDB, Cognito, S3 and backend code work in writing first, then build and test the export and import path against your own data before anything moves to production.

How we scope

Inventory every Amplify-managed DynamoDB table, Cognito user pool, S3 bucket and Lambda function that holds data or logic
Confirm whether point-in-time recovery is enabled on each DynamoDB table before any export is planned
Agree in writing which export formats, user fields and file paths are in scope, and which are excluded
Engagements are fixed-scope, with deliverables and timelines agreed before work starts

How we build

Build repeatable export scripts for DynamoDB JSON or Ion output and reshape them into the target schema
Map Cognito user attributes through ListUsers, and plan how users re-authenticate without exported passwords
Rewrite the TypeScript and CDK backend logic as target platform configuration, then test it against sample data
Copy S3 objects with checksums and record how each file maps to its new storage path

How we hand over

Document the export procedure, data mapping, user migration steps and rollback plan in a runbook you keep
Provide a validation report comparing record counts, attribute values and file checksums between source and target
Deliver the self-hosted environment with secrets handled and access controls documented for your team
Walk your engineers through operating the platform, including what is no longer provided by Amplify

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Plan upgrades of the self-hosted platform against its release notes and change logs, with a tested backup first
Re-run security testing of the migrated application and its APIs when your scope calls for it
Confirm with your team who owns patching, backups and incident response once the platform is live