AWS Schema Conversion Tool (SCT) — Heterogeneous Schema Conversion
Recap: Where We Left Off
Day 45 established MGN as the rehost workhorse: continuous block-level replication from source servers into a staging area in AWS, with test and cutover instances launched on demand so the real cutover window stays short. The whole design rests on one assumption — that the thing being moved is a server, and that whatever runs on it will keep running unchanged once it lands on EC2. That assumption is exactly what breaks the moment the workload is a database engine rather than an application.
Today sets up the same trap in a different service. MGN's promise is that the source and target are functionally identical, so nothing inside the machine needs to be understood. SCT's promise is narrower and much more conditional: it will translate schema and procedural code between engines, but it will not promise that the translation is complete, and the gap it leaves behind is where heterogeneous migrations actually fail. The same instinct that makes MGN feel safe — "the tool handles it" — is the instinct that gets teams into trouble here, because SCT reports its own incompleteness and the report is easy to skim past.
Foundations You'll Need Today
Today's topic sits on top of a handful of database ideas that the rest of this curriculum treats as background knowledge. None of them are complicated, but the day's whole argument depends on them, so it is worth spending a few minutes making them concrete before the real material starts.
A Database Engine Is Software, Not the Data
When people say "the database," they usually mean two different things at once. One is the data itself — the rows and columns of actual information. The other is the engine: the software program that stores that data on disk, answers queries against it, enforces rules about what values are allowed, and decides how to execute a request efficiently. Oracle, Microsoft SQL Server, MySQL, and PostgreSQL are all engines. They all speak SQL, which is why they look interchangeable from a distance, but they are separate products built by different companies with different internal designs, different performance characteristics, and — critically for today — different dialects of SQL and different ways of writing the logic that runs inside them. Moving data from one engine to another is not like copying a file; it is like translating a document into a language that is similar but not identical.
Schema vs. Data: The Structure and the Contents
The schema is the structure: the list of tables, what columns each table has, what type of value each column holds (a number, a date, a piece of text), which columns are indexed for fast lookup, and which rules must hold true. The data is what fills that structure — the actual rows. This distinction matters because the two can be moved separately and by different tools. You can build an empty structure on a new engine weeks before any real data arrives, and you can move data into a structure that already exists. Almost every migration mistake in today's material comes from blurring these two things together, so keep them separate in your head: structure first, contents second.
Stored Procedures and Procedural Code
Most of the time, an application sends a query to the database and gets a result back. But databases can also hold logic of their own — small programs that live inside the database and run there. These are called stored procedures, functions, triggers, and views, and collectively they are "procedural code." A stored procedure might, for example, take an order ID, check inventory, apply a discount rule, and write a record, all without the application having to orchestrate each step. Each engine has its own language for writing this logic: Oracle uses PL/SQL, SQL Server uses T-SQL, PostgreSQL uses PL/pgSQL. They share a family resemblance but differ in the details — how they handle errors, how they loop over results, which built-in functions exist. This is the part of a database that does not travel cleanly between engines, and it is the reason today's tool exists at all.
Homogeneous vs. Heterogeneous Migration
A migration is homogeneous when the source and target are the same engine — Oracle to Oracle, MySQL to MySQL. In that case the structure and the logic move as-is, because nothing needs translating. A migration is heterogeneous when the engine changes — Oracle to PostgreSQL, SQL Server to MySQL. Now every table definition, every index, and every piece of procedural code has to be translated into the target engine's dialect, and some of it will not translate cleanly. That single word — homogeneous or heterogeneous — determines which tools you need, how long the project takes, and where the risk lives. It is the first thing to identify in any migration scenario.
Change Data Capture (CDC)
Moving a large database takes time — hours or days for a big one. During that window, the original database keeps receiving new writes from live users, so by the time the copy finishes, it is already out of date. Change data capture solves this by watching the source database for every insert, update, and delete that happens after the initial copy began, and replaying those changes onto the target. The result is that the target stays in sync with the source continuously, and the final switchover can happen in minutes rather than requiring a long freeze. You will see CDC mentioned in today's quiz and in the tool comparison, and it is the mechanism that makes "minimize downtime" migrations possible.
With that grounding, here's why SCT exists and what problem it actually solves.
1. Why SCT Is on the Exam
SCT exists because of a specific architectural problem: relational database engines are not interchangeable at the schema level, and the parts that differ most are the parts that carry business logic. A table definition is mostly portable — column types map with varying degrees of fidelity, indexes and constraints translate with predictable caveats. Stored procedures, functions, triggers, and views are not portable in the same way, because they are written in a vendor-specific procedural dialect. Oracle's PL/SQL, SQL Server's T-SQL, and PostgreSQL's PL/pgSQL share syntax ancestry but diverge on error handling, cursor semantics, dynamic SQL, package structure, and dozens of built-in functions that have no direct equivalent. A migration that only moves tables and data leaves the application calling procedures that no longer exist.
That is the gap SCT fills, and it is why the service shows up in SAP-C02 scenarios that describe a heterogeneous engine change — Oracle to Aurora PostgreSQL, SQL Server to Aurora MySQL, Teradata or Netezza to Redshift. The exam does not test SCT in isolation; it tests whether you recognize that a heterogeneous migration is a two-tool problem. SCT handles schema and code, DMS handles data and ongoing change capture, and neither substitutes for the other. Scenarios that describe "minimize downtime" or "migrate with minimal application changes" while also changing the engine are testing whether you know both tools are required and in what order they run.
The domain mapping is Domain 3, Migration and Modernization, which is the smallest of the four domains by weighting but disproportionately represented in scenario questions because migration decisions combine so many other domains — networking for the transfer path, security for credentials and encryption, cost for the target engine choice. SCT specifically tests the boundary between "the tool did it" and "a developer still has to do it," which is the single most common misreading of what a conversion tool delivers.
There is also a quieter reason the topic appears: it is a clean test of whether you understand that schema conversion and data migration are separable, independently schedulable activities. You can convert and validate schema weeks before you move a single row. Teams that understand this sequence their migration differently from teams that treat it as one event, and the exam rewards the former.
2. How SCT Actually Works
SCT is a desktop application, not a managed AWS service. That single fact drives most of its operational characteristics. You install it on a workstation or a Windows EC2 instance, and it connects outward to the source database, the target database, and — optionally — to an S3 bucket that holds the project file and the assessment report. There is no SCT control plane in your account, no IAM role it assumes on your behalf, and no service quota to raise. The tool runs where you run it, and the credentials it uses are the ones you configure in its connection profiles.
Internally, SCT works in two distinct phases that are worth separating in your head. The first is assessment: it connects to the source, reads the catalog, and produces an assessment report that classifies every schema object by how much manual effort its conversion will require. The report groups objects into categories — those that convert automatically, those that convert with simple actions, and those that require complex or manual rewriting. The headline number people quote is the percentage of objects that convert automatically, but the more useful output is the list of objects in the manual bucket, because that list is your actual project plan.
The second phase is conversion. SCT reads the source DDL and procedural code and emits target-engine DDL and code, applying a translation ruleset that is engine-pair specific. Oracle-to-PostgreSQL and SQL-Server-to-MySQL are different rulesets with different coverage. Where a construct has a clean equivalent, SCT emits it directly. Where it does not, SCT emits a commented-out block with an action item explaining what a developer needs to decide — this is the mechanism behind the "conversion with simple actions" category. Where the construct is structurally incompatible, SCT may emit nothing usable at all and flag the object for manual rewrite.
The output is not applied automatically. SCT generates a SQL script that you review, edit, and then run against the target yourself. This is deliberate: the tool's authors assume a human will read the generated code before it touches a database. Teams that treat the generated script as a deployable artifact and pipe it straight into the target are skipping the step the tool was designed around, and the failure mode is subtle — the script runs, the schema exists, and the application breaks weeks later on a code path nobody tested.
One more mechanism detail matters for planning: SCT can also convert application-side SQL embedded in code, via its application conversion projects, but that capability is narrower and less reliable than schema conversion. Treat it as a helper for finding embedded SQL, not as an automated application port.
3. The Core Decision Boundary: Homogeneous vs. Heterogeneous
Every SCT scenario question reduces to one fork: is the target engine the same as the source engine, or different? If it is the same, SCT is not in the picture at all — you are doing a homogeneous migration, DMS alone handles it, and the schema moves as-is because there is nothing to translate. If the engine changes, SCT becomes mandatory, because DMS will happily copy data into a target whose schema does not exist yet and fail in ways that are tedious to diagnose.
The fork is not just about whether to use SCT. It determines the entire shape of the project: the timeline, the skill mix on the team, the risk profile, and the cutover strategy. A homogeneous migration is largely an infrastructure exercise. A heterogeneous migration is a software project with a database attached, because someone has to own the manual remediation list.
| Dimension | Homogeneous (same engine) | Heterogeneous (different engine) |
|---|---|---|
| Schema conversion tool | Not needed | SCT required |
| Data migration tool | DMS | DMS (after schema exists) |
| Procedural code | Moves unchanged | Converted, partially, with manual remediation |
| Application changes | Typically none | Often required for dialect-specific SQL |
| Primary risk | Cutover timing and data volume | Untested code paths and silent semantic drift |
| Typical timeline driver | Transfer bandwidth | Developer remediation effort |
| Rollback complexity | Moderate | High — two engines, two schemas, two code paths |
The exam pattern here is a scenario that mentions a specific engine change and then asks what additional step is required. The distractor set usually includes "use DMS with the schema conversion option enabled" — which is not a thing — or "use SCT to migrate the data," which inverts the tools' roles. The correct answer names SCT for schema and code, DMS for data, and typically adds that manual remediation of unconverted objects is expected.
A second, subtler boundary sits inside the heterogeneous case: whether the target engine choice was driven by licensing cost, by a managed-service preference, or by an existing team skill base. That choice determines how much of the procedural code has a natural home. Moving Oracle PL/SQL to Aurora PostgreSQL means rewriting packages into functions and schemas; moving SQL Server T-SQL to Aurora MySQL means a larger rewrite still, because the procedural dialects are further apart. SCT's assessment report quantifies this before you commit, which is the main reason to run assessment early rather than as a formality.
4. Conversion Modes and Their Tradeoffs
SCT's configuration surface is smaller than DMS's, but the choices still change the shape of the work. The first and most consequential is the engine pair you select when creating the project. SCT supports a specific matrix of source and target engines, and the coverage of that matrix is uneven — some pairs convert the large majority of objects automatically, others leave substantially more manual work. Choosing a target engine that is well covered by SCT's ruleset is a legitimate architectural input, not a shortcut, because it directly reduces the remediation backlog.
The second choice is scope: schema-only conversion, or schema plus code objects. Converting tables, indexes, and constraints is comparatively mechanical. Converting stored procedures, functions, triggers, and views is where the assessment report's manual bucket fills up. Some teams deliberately split these into two passes — get the schema converted and the data flowing first, then port procedural logic incrementally while the old system is still authoritative for those code paths. That staging is a real strategy, and it is worth recognizing in scenarios that describe a phased cutover.
The third choice is how you handle the generated action items. SCT emits three broad categories of output, and each implies a different cost.
| Output category | What SCT emits | Effort implied |
|---|---|---|
| Automatic conversion | Working target-engine DDL or code | Review only |
| Conversion with actions | Code plus inline action items describing a decision | Developer edits, usually small |
| Manual rewrite required | Comment block or nothing usable | Full reimplementation against target dialect |
The trap in this table is that the middle category is where estimates go wrong. "Conversion with actions" sounds cheap, and for a simple type mapping it is. For a cursor-heavy procedure with vendor-specific error handling, the action items can amount to a rewrite with extra steps. The assessment report's effort estimate is a starting point, not a commitment, and the only reliable way to size the middle bucket is to have a developer read a representative sample of the generated output.
Finally, there is the question of where the project file and reports live. SCT can store its project in a local file or in S3, and the assessment report can be exported for sharing. For a team migration, storing the project in S3 is the difference between one person's laptop being the source of truth and the project being a shared artifact. It is a small configuration choice with an outsized effect on whether the remediation list is visible to the people who have to work it.
5. Sizing, Limits, and What Actually Constrains You
SCT has no service quotas in the AWS sense, because it is not a service. What constrains an SCT project is the size and complexity of the source schema, the throughput of the connection between the SCT workstation and the databases, and the number of developer hours available to work the manual bucket. Of those, the last is almost always the binding constraint, and it is the one that does not appear in any AWS documentation table.
The connection path matters more than people expect. SCT reads the source catalog and, for assessment, samples data to estimate conversion effort. If the source database is on-premises and SCT runs on a workstation in the same building, that is fine. If SCT runs on an EC2 instance in AWS and the source is on-premises, every catalog read crosses the hybrid link, and a large schema with thousands of objects can make assessment slow enough to be annoying. Running SCT close to the source — or close to the target, if you are converting against a live target — is a practical sizing decision.
On the target side, the constraint is that the target database must exist and be reachable before you can validate converted DDL against it. SCT can generate DDL without a live target, but it cannot tell you whether the generated DDL actually applies cleanly. For a large migration, provisioning the target Aurora or RDS instance early — even at a small instance size — turns schema conversion from a paper exercise into a tested one.
| Constraint | Where it bites | Mitigation |
|---|---|---|
| Source schema object count | Assessment runtime and report size | Run SCT near the source; scope assessment to one schema at a time |
| Procedural code volume | Manual remediation backlog | Sample the middle bucket early to size real effort |
| Hybrid link throughput | Catalog reads and data sampling | Co-locate SCT with the source or use a Direct Connect path |
| Target availability | Validating generated DDL | Provision the target early, even at minimum size |
| Developer hours | Everything downstream of the report | Treat the manual bucket as the project plan, not a footnote |
One number worth internalizing without over-trusting: a conversion-completeness figure in the low-to-mid nineties is a normal, healthy result for a well-covered engine pair, and it still means a meaningful number of objects need human attention. The percentage is computed over objects, not over lines of code or over business criticality, so a schema where the 5% that failed to convert happens to be the billing procedures is a much harder migration than the number suggests. Read the list, not the percentage.
6. Failure Modes and What They Look Like in Production
The most common failure is not a tool failure at all — it is a planning failure where the conversion percentage is treated as a completion metric. The migration is declared ready because SCT reported a high automatic conversion rate, the schema is applied, DMS copies the data, and the application starts throwing errors on the first code path that touches an unconverted procedure. The symptom is a cluster of runtime errors that all trace back to a small number of database objects, and the first diagnostic move is to diff the assessment report's manual bucket against the objects the application actually calls.
The second failure mode is silent semantic drift. SCT converts a construct to something that is syntactically valid in the target dialect but behaves differently at the edges — null handling in a comparison, implicit type coercion in an arithmetic expression, ordering guarantees in a query without an explicit ORDER BY, or date arithmetic across different calendar semantics. Nothing errors. Results are subtly wrong. This is the hardest class of bug to find because there is no exception to trace, and it is why converted procedural code needs test coverage against known-good outputs rather than just a successful compile.
The third is a data-type fidelity problem that surfaces late. A source column type maps to a target type that is close but not identical in range or precision, and the problem only appears when a value outside the target's range arrives — months after cutover, from a customer nobody was thinking about. The mitigation is to review the type mapping table SCT produces rather than accepting it, and to check the widest and most extreme values in each converted column against the target type's limits.
The fourth is an operational failure specific to the tool's desktop nature: the project file lives on one engineer's machine, that engineer leaves, and the remediation list is gone. There is no service-side record of what was converted or what was flagged. Storing the SCT project in S3 and exporting the assessment report into the migration's shared documentation is the only defense, and it is easy to skip because the tool works fine without it right up until it doesn't.
7. The Operational and SRE Angle
SCT itself has no runtime, so there is nothing to monitor in the traditional sense — no CloudWatch metrics, no alarms, no SLO. What it produces, however, has a direct and permanent effect on the operational characteristics of the target database, and that is where the SRE thinking belongs. Converted procedural code is new code running in production for the first time, and it deserves the same treatment as any other new code: staged rollout, comparison against the old system's outputs, and a rollback path that does not require re-converting anything.
The practical pattern is a parallel-run period. The old engine stays authoritative while the converted procedures run against a copy of production data and their outputs are compared to the originals. Discrepancies are the semantic drift from the previous section, caught before they reach a customer. This is expensive in infrastructure and cheap in incident cost, and for any procedure that touches money, inventory, or access control it is not optional.
Once cut over, the operational surface is the target database's own — connection counts, query latency, lock contention, replication lag if DMS is still streaming. The one SCT-specific artifact worth keeping in the runbook is the mapping from each converted object back to its source object, so that when a query plan regresses or a procedure behaves oddly, the on-call engineer can find the original definition and compare. Without that mapping, debugging converted code means reverse-engineering what it used to be.
There is also a change-management angle. After cutover, the source schema is frozen and the target schema becomes the live one. Any change that would have been made to the source must now be made to the target, and the two will diverge immediately. Teams that keep the source database running "just in case" for months without a defined decommission date accumulate a second system to maintain and a growing ambiguity about which one is authoritative. Set the decommission date when you set the cutover date.
8. Edge Cases and Exam Gotchas
The single most reliable gotcha is the tool-role inversion. SCT converts schema and code; DMS moves data. Any answer that has SCT migrating rows, or DMS converting stored procedures, is wrong regardless of how well the rest of the option reads. The exam leans on this because the two tools are always mentioned together and the division of labor is easy to blur under time pressure.
The second gotcha is the assumption that a high conversion percentage means the migration is nearly done. It does not. The percentage counts objects, and the objects that fail are disproportionately the complex ones that carry business logic. A schema with 95% automatic conversion can still have weeks of developer work in the remaining 5%.
The third is forgetting that SCT is a client-side tool. Answers that describe "enabling SCT in the AWS console" or "attaching an IAM role to SCT" are describing something that does not exist. SCT runs on a machine you control and connects with credentials you supply.
The fourth is the ordering mistake: running DMS before the converted schema has been applied and validated. DMS will attempt to write into a target that does not have the right tables, and the errors it produces are about the target, not about the missing schema step, which sends people down the wrong diagnostic path.
The fifth is treating the generated script as deployable without review. SCT's output is a draft. The action items embedded in it are instructions, not comments.
The sixth, and the one most likely to appear in a scenario with a twist, is the homogeneous case. If the scenario says the engine is unchanged, SCT is a distractor. The correct answer is DMS alone, and the presence of procedural code in the source does not change that, because same-engine procedural code moves as-is.
9. SCT vs. the Tools It Gets Confused With
SCT sits in a small cluster of migration tools that all sound similar in a scenario description and do genuinely different jobs. The confusion is almost always about which layer of the stack each tool operates on: schema and code, data and change streams, files and objects, or whole servers.
| Tool | Layer | Use it when… |
|---|---|---|
| AWS SCT | Schema and procedural code | The target engine differs from the source engine |
| AWS DMS | Data and ongoing changes | You need to move rows, with or without CDC, into an existing schema |
| AWS DataSync | Files and objects | You are moving NFS/SMB/HDFS data to S3, EFS, or FSx — not database-aware |
| AWS MGN | Whole servers | You are rehosting a server and keeping its OS and software unchanged |
| AWS Snow Family | Physical media | The network is the bottleneck and offline transfer is faster |
The pairing rule to memorize is that SCT and DMS are complements, not alternatives, and they run in that order. SCT first, because the target schema must exist before data can land in it. DMS second, because it needs somewhere to write. If a scenario describes a heterogeneous migration and asks for the complete tool set, the answer names both.
The distinction from DataSync is worth holding onto because both tools are described as "migration" tools and both handle data. DataSync is file- and object-oriented and has no concept of a database schema, a table, or a stored procedure. If the source is a database and the target is a database, DataSync is the wrong tool no matter how the scenario is phrased. If the source is a file share and the target is S3 or EFS, DataSync is the right tool and SCT is irrelevant.
Against MGN, the boundary is the unit of migration. MGN moves a machine; SCT moves a schema. A scenario that describes rehosting an application server and its database together, with no engine change, is an MGN scenario. A scenario that describes keeping the application where it is but changing the database engine underneath it is an SCT scenario. The two can appear in the same migration program, on different workloads, and the exam will sometimes describe both to see whether you keep them straight.
Hands-On Lab: Convert an Oracle Schema to Aurora PostgreSQL (60 min)
This lab walks through a heterogeneous conversion end to end: assess, convert, review, and validate. The goal is not to produce a working application but to see exactly where SCT stops and a developer has to start, because that boundary is the thing the exam tests.
1. Provision the target. Create an Aurora PostgreSQL cluster in a private subnet, at the smallest instance size that supports your testing. Note the endpoint, the database name, and the credentials. You will need a live target to validate generated DDL, and provisioning it first means you are never blocked waiting on it later.
2. Prepare a source schema with real procedural content. If you do not have an Oracle instance available, use a sample schema that includes at least one table with a vendor-specific type, one view with a function call in its definition, and two or three stored procedures — ideally one with a cursor loop, one with exception handling, and one that uses a package-level variable. The point is to have objects that fall into all three output categories, not to have a large schema.
3. Install SCT and create the project. Install the desktop tool on a machine with network reachability to both databases. Create a new project, select Oracle as the source and Amazon Aurora (PostgreSQL-compatible) as the target, and configure both connection profiles. Store the project file in S3 rather than locally, so the artifact survives the lab and is shareable.
4. Run the assessment. Execute the database assessment and open the generated report. Read it in this order: the summary percentage first, then the list of objects requiring manual conversion, then the effort estimate. Write down the count of objects in each of the three categories. This is the number that determines your project timeline, not the headline percentage.
5. Convert the schema. Run the conversion for the schema objects only — tables, indexes, constraints, sequences. Review the generated DDL. Look specifically for type mappings you would not have chosen, and for any column where the target type's range is narrower than the source's. Apply the script to the Aurora cluster and confirm it runs cleanly.
6. Convert the code objects. Now convert the views, functions, and stored procedures. Open the generated output and find the action items. For each one, classify it: is this a mechanical substitution, a semantic decision, or a full rewrite? Count how many fall into each bucket. Compare that count to what the assessment report predicted — the gap between prediction and reality is the lesson.
7. Validate against the target. Apply the converted code objects to Aurora. Where a procedure converted cleanly, call it with representative inputs and compare the output to what the Oracle version returns for the same inputs. Where it did not convert, note the specific construct that defeated the ruleset — this is the list you would hand to a developer.
8. Write the remediation plan. Produce a short document listing every object in the manual bucket, the reason it failed, and a rough effort estimate. This is the artifact a real migration would be planned from, and producing it is the actual deliverable of the lab.
Scenario Question Drills (20 min)
Q1. A team is migrating an on-premises Oracle database to Amazon Aurora PostgreSQL. They plan to use AWS DMS with full load plus CDC. What critical step is missing from their plan?
Q2. SCT's assessment report shows 94% automatic conversion for an Oracle-to-PostgreSQL migration. The project manager reads this as "94% done." What is wrong with that interpretation?
Q3. Where does AWS SCT run?
Q4. A migration moves an on-premises MySQL database to Amazon RDS for MySQL. The application uses stored procedures. Which tools are required?
Q5. After applying SCT-converted stored procedures to Aurora PostgreSQL, the application runs without errors but produces subtly incorrect totals on some reports. What is the most likely cause?
Q6. A team wants to move 40 TB of NFS file share data to Amazon EFS on a nightly schedule with integrity validation. Which tool fits?
Q7. During an SCT conversion, a complex Oracle package with vendor-specific error handling produces a commented-out block with action items rather than working code. What does this mean for the project plan?
Q8. Which statement correctly describes the division of labor between SCT and DMS?
Q9. A migration team runs DMS before applying the SCT-converted schema to the target. What is the likely outcome?
Q10. An engineer asks how to grant SCT the IAM permissions it needs to read the source database. What is the correct response?
Q11. A converted column that held large numeric values in Oracle is mapped to a PostgreSQL type with a narrower range. When does this problem surface?
Q12. A migration program includes both rehosting 200 application servers and changing a database engine from SQL Server to Aurora MySQL. Which tools map to which workload?
Q13. Why does SCT generate a SQL script for review rather than applying converted DDL directly to the target?
Q14. A team wants to reduce the risk of converted procedures behaving differently from the originals. Which approach addresses this most directly?
Q15. Six months after a heterogeneous migration cutover, the source Oracle database is still running and receiving occasional schema changes from a team that did not know the migration was complete. What is the underlying process failure?
Peek into Tomorrow
Everything in this day assumed the thing being migrated is a database, and that the tools involved understand what a table, a schema, and a stored procedure are. That assumption is doing a lot of quiet work. It is why SCT can read a catalog and produce an assessment, why DMS can capture changes at the row level, and why the whole heterogeneous migration story has a coherent shape at all.
The open question is what happens when the data has no schema to convert — when it is a file share full of documents, a directory tree of images, or an object store with millions of keys and no relational structure whatsoever. None of the machinery from today applies. There is no catalog to assess, no procedural code to translate, and no concept of a row-level change to capture. What replaces it is a different set of concerns entirely: how you keep a transfer running for days without saturating the link that production also depends on, and how you know — with evidence rather than hope — that every file arrived intact and none were silently skipped. Tomorrow's topic is the tool that answers those questions, and the interesting part is how much of its design is about verification rather than transfer.
Sources
- AWS Schema Conversion Tool User Guide — What Is AWS SCT?
- AWS SCT — Working with the Assessment Report
- AWS SCT — Converting Database Schemas
- AWS DMS — Best Practices for Database Migration
- AWS Prescriptive Guidance — Migrating Oracle Databases to AWS
- AWS Prescriptive Guidance — Migrating Microsoft SQL Server to AWS
- Amazon Aurora User Guide — Working with Aurora PostgreSQL
- AWS Schema Conversion Tool product page