DC2 was the workhorse Redshift node type from 2017: local SSD storage, compute and storage scaled together, and a price that made sense for warehouses under a few tens of terabytes. In 2026 it is the legacy tier. RA3 nodes (compute with Redshift Managed Storage on S3) and Redshift Serverless are where every new feature lands, and several features that customers now ask for, zero-ETL integrations, data sharing, and cross-region sharing among them, simply do not work on DC2. If you still run DC2, the question is not whether to move but how.
Where you can go
RA3 provisioned. The direct replacement. Storage is decoupled from compute and billed separately as RMS; you size nodes for compute and the data fits regardless. ra3.xlplus is the entry point, ra3.4xlarge and ra3.16xlarge above it. Reserved pricing is available.
Serverless. No nodes at all; billed per RPU-hour while queries run. The better target for workloads that are idle much of the day. See RA3 vs Serverless in 2026 for how to choose.
Both targets are reached the same way: a snapshot of the DC2 cluster restored into the new environment.
Sizing translation
DC2 sizing was driven by storage: you bought enough nodes to hold the data. RA3 and Serverless sizing is driven by compute, so the translation is not one-to-one.
For RA3, AWS publishes recommended mappings (for example, a dc2.large cluster of a given size maps to a small number of ra3.xlplus nodes, and dc2.8xlarge to ra3.4xlarge). Treat these as a starting point. The console also offers a recommendation based on your cluster's observed usage. In practice, because DC2 clusters were often oversized to hold data, the RA3 cluster that replaces one is frequently smaller in node count and cheaper, even before reserved pricing.
For Serverless, ignore the node count entirely. Restore the snapshot into a namespace, attach a workgroup with a low base capacity (32 RPUs is a reasonable first guess for a cluster that was dc2.large x 4 to 8), run the real workload for a week, and adjust.
The migration path
- Inventory. Every connection string, IAM role, VPC security group, parameter group setting, scheduled query, and WLM rule on the DC2 cluster. This is most of the work.
- Snapshot. Take a manual snapshot of the DC2 cluster at a quiet time (or use the latest automated one).
- Restore. Restore into a new RA3 cluster (choose the node type and count at restore time) or into a Serverless namespace. The restore is an S3-to-RMS copy; for a 10 TB cluster, expect hours, not minutes, and the new environment is queryable before the copy completes (data is pulled on demand).
- Reattach. IAM roles, security groups, KMS keys, parameter group values (RA3) or workgroup configuration (Serverless). Enhanced VPC routing and the subnet group need re-creating for Serverless.
- Parallel run. Point a copy of your ETL and a subset of BI users at the new environment. Compare query timings and, for Serverless, compare RPU-hours to the cost model.
- Catch-up. Either re-snapshot and restore once more at cutover (simple, but the new environment's changes are lost, so keep it read-only) or replay the ETL delta onto the new environment.
- Cutover. Change the endpoints. For RA3 you can rename the new cluster to the old cluster's identifier so the endpoint hostname stays the same, which saves touching every client. Serverless has a new endpoint; update the connection inventory from step 1.
- Decommission the DC2 cluster after a retention period. Keep a final snapshot.
Elastic resize from DC2 to RA3 is also available for some configurations and avoids the snapshot step, but it takes the cluster through a read-only window and offers less control; we prefer the restore path for anything larger than a few terabytes.
What changes in behaviour
- Storage is elastic and billed separately. Tables can grow without a resize. RMS cost appears as a new line on the bill; stale data you never cleaned up now has a visible price. Run the stale-table audit after migration.
- Cold data reads from S3. RA3 nodes cache hot blocks locally and fetch the rest from RMS. The first scan of a cold table after restore is slower than DC2's local SSD; subsequent scans are comparable or faster. Warm the cache by running the dashboard queries before cutover.
- Features unlock. Data sharing, zero-ETL, cross-region snapshot copy, and (on Serverless) scale-to-zero are all now available. Plan to use them; they are the reason to migrate.
- WLM on Serverless. Manual WLM queues do not exist. Query priorities and query monitoring rules are the equivalent. Export your QMR definitions before you start.
Gotchas from real migrations
- Interleaved sort keys. They survive the restore but should not. Convert to
SORTKEY AUTOon the new environment (see our sort key guide); theVACUUM REINDEXjobs that maintained them are no longer needed. - Hard-coded node counts. Scripts that computed file counts for COPY from the slice count, or that sized temp tables by node, need revisiting.
- Reserved DC2 nodes. If you hold a DC2 reservation, check its end date; AWS has offered conversion paths for some reservation types, and your account team can confirm what applies.
- Encryption. An unencrypted DC2 snapshot restores to an unencrypted RA3 cluster; Serverless namespaces are always encrypted. Plan the KMS key and any cross-account snapshot sharing accordingly.
- Legacy encodings. DC2-era tables created with explicit
ENCODE lzokeep those encodings. Rebuild the largest ones for AZ64/ZSTD after the move, when you are already measuring. - Spectrum external schemas. These come across in the snapshot, but the IAM role they reference must be attached to the new environment or every external query fails on day one.
Effort
For a single DC2 cluster with a clean inventory, two to three weeks end to end, most of it parallel-run time. For an estate with undocumented consumers, the inventory step dominates and we budget a week for it alone.
We have done this migration many times and have a runbook for it. If you would like it run, or reviewed, see Redshift Administration and Redshift Serverless Migration & Right-Sizing.