RheoData Blog | Oracle GoldenGate migration strategy

I've had this conversation more times than I can count. A team tells me they're doing a GoldenGate migration. Two questions in, it becomes clear they aren't migrating anything — they're standing up a replication topology and calling it a migration because the project has an end date on a slide somewhere. The reverse happens just as often. A team says they're setting up replication between two systems. A few questions in, I find out the source database is going away in six months and nobody is staffed to run replication after that. They don't need replication. They need a migration plan. Quick answer: Oracle GoldenGate can perform both data migration and ongoing replication, but they are not the same job. Migration is a finite, one-time project that ends at cutover and teardown. Replication is a continuous, permanent practice that requires monitoring, ownership, security hardening, and a long-term operating model. Choosing the wrong framing leads to operational risk, runaway licensing and storage costs, and audit exposure under SOX, HIPAA, PCI-DSS, and GDPR. GoldenGate is one of the few tools in the Oracle ecosystem that can sit in the middle of either conversation. That flexibility is a strength, but it's also why so many teams end up running the wrong play. What Is the Difference Between Migration and Replication in Oracle GoldenGate? Migration is a project. Replication is a practice. A migration has a beginning, a middle, and a definite end. You're moving from System A to System B. There is a cutover. There is a sunset. The GoldenGate configuration exists to keep the source and target in sync long enough for you to verify, switch traffic, and walk away. When it's done, the Extract is shut down, the parameter files are archived, and the team moves on. Replication has none of those things. Both systems stay alive. The data flows in one direction or two, and it keeps flowing. The Extract is not temporary scaffolding — it is permanent infrastructure. Someone monitors lag. Someone responds to ABEND alerts at 2 a.m. Someone patches and upgrades and tests new releases. Someone owns the trail file directories, the credential aliases, the heartbeat tables, and the conflict resolution logic. Dimension Migration Replication Duration Finite, ends at cutover Continuous, ongoing Primary goal Move data from A to B Keep A and B in sync Staffing model Project team with end date Operations team with on-call rotation Monitoring focus Validation, row counts, cutover readiness Lag thresholds, ABEND alerts, trail file growth Lifecycle Designed for teardown Designed for years of operation Security posture Often relaxed for project speed Must enforce least privilege Patching cadence Not required post-cutover Required, ongoing Licensing exposure Bounded to project window Permanent line item These are different jobs. They demand different designs, different staffing, and different conversations with the business. Where Teams Get This Wrong: Migrations That Become Accidental Replications The most common mistake I see: a team uses GoldenGate to migrate from on-prem Oracle to Oracle Cloud Infrastructure (OCI), to Exadata Cloud@Customer, or to a downstream analytics target like Snowflake or Google BigQuery. The project succeeds. And then nobody turns the replication off. The cutover happened. The original target became the new source of truth. But the GoldenGate processes are still running, often in both directions, consuming archive logs and trail file storage that nobody is tracking. Six months later, somebody asks why the original source database's archive log destination keeps filling up. Twelve months later, somebody asks who owns the GoldenGate environment. The answer is: nobody. It was a project. The project ended. The replication did not. The opposite mistake is just as expensive. A team is told to set up replication for reporting or build a CDC pipeline into Snowflake. They scope it like a migration — finite hours, finite budget, hand it off when it's running. They don't budget for monitoring tooling. They don't define an on-call rotation. They don't write runbooks for common failure modes like log mining gaps, supplemental logging changes, or DDL that wasn't accounted for. Six weeks in, the first ABEND happens at 11 p.m. on a Friday, and nobody knows who to call. Both failures come from the same root cause: confusing the tool with the job. What Does GoldenGate Migration Actually Look Like When Done Right? When the job is genuinely a migration, GoldenGate is a vehicle, not a destination. The conversation is about cutover risk, downtime windows, and validation. Your team should be talking about: How long the initial load takes and whether you're using Oracle Data Pump, RMAN, or a parallel CDC start point How you validate row counts and content between source and target before cutover How you handle DDL that shows up mid-migration, especially in a jump from Oracle Database 19c to 23ai, where the long-term release introduces features like AI Vector Search and JSON-relational duality What the rollback plan looks like if cutover fails When you actually tear the configuration down The parameter files for a migration can be relatively simple. You aren't designing for a decade. You're designing to get from A to B without losing data and without surprising the business. The discipline here is in the project plan and the validation, not in the long-term operating model. What Does an Oracle GoldenGate Replication Topology Demand Operationally? A replication topology is a system you operate. That changes everything about how it should be designed and staffed. You need monitoring that goes beyond is the process up. You need lag thresholds, trail file growth alerts, and visibility into the long-running transactions that will eventually trip you up. You need credential management — and if your Extract is still running under a db_owner or SYSDBA-equivalent account because that's what the migration project used, that's a problem that should have been fixed before the project closed, not after the auditor finds it. You need a patching strategy. Oracle GoldenGate Microservices releases come out regularly. Bugs get fixed. The version you stood up two years ago is not the version you should be running today. Somebody on your team needs to own that lifecycle, and that ownership needs to be documented before the original engineers move to other projects. You need DR and HA conversations. If the GoldenGate hub goes down, what breaks downstream? If the source database fails over, does the Extract pick up cleanly with no data gap? These aren't migration questions. They're operational questions, and they only matter if replication is going to live past cutover. Least privilege is non-negotiable for any GoldenGate Extract running past cutover. A migration that was never turned off is the single most common source of unbudgeted GoldenGate licensing costs and unmanaged audit findings I encounter in the field. Why This Matters to Your Organization The cost of confusing these two jobs shows up in three places, and all three eventually land on a leadership desk. Operational risk is the first. A replication topology with no owner is a silent liability. It works until it doesn't, and when it doesn't, the people who built it are usually long gone or assigned to the next project. The first time the business notices is also the first time the business is unhappy. Cost creep is the second. GoldenGate licensing isn't free. Trail file storage isn't free. Network egress on cross-cloud replication — particularly when you're moving data between OCI, Microsoft Azure, AWS, or Google Cloud — isn't free. A migration that became an accidental replication is paying for infrastructure nobody scoped, in budgets nobody owns. Audit and compliance exposure is the third. If your replication is moving data subject to SOX, HIPAA, PCI-DSS, or GDPR, somebody is going to ask who owns it, who has access to it, and how changes are controlled. It was a project we never turned off is not an answer that holds up in front of an auditor, and it's certainly not an answer that holds up in front of a board. The fix is to decide, up front, which job you're actually doing — and to staff and govern accordingly. If it's a migration, plan the end. If it's replication, plan the operating model. A Disciplined Approach When we engage on these projects at RheoData, the first conversation is almost never about parameter files or topology diagrams. It's about which of the two jobs the customer is actually signing up for. Once that's clear, the rest of the design falls into place. If it's a migration, we build for cutover and teardown. We define success criteria, the validation plan, and the date the GoldenGate environment goes away. We don't leave it running just in case — that's how accidental replication is born, and it's how technical debt becomes audit findings. If it's replication, we build for operation. We define ownership, monitoring, on-call, patching cadence, security posture, and DR. We assume the system will live for years, and we design accordingly. We do not let a least-privilege account get skipped because the project deadline is tight. Frequently Asked Questions Can Oracle GoldenGate be used for both migration and replication? Yes. Oracle GoldenGate is designed to support both one-time data migrations and continuous data replication. The technology is the same — Extract, Replicat, trail files, parameter files — but the operating model, staffing, and security posture required for each are fundamentally different. Treating them as the same project is the most common architectural mistake I see in the field. What happens if you don't shut down GoldenGate after a migration cutover? A migration that is never shut down becomes an unmanaged replication topology. Archive logs continue to be mined, trail files continue to grow, GoldenGate licensing continues to apply, and nobody owns the environment operationally. This creates silent operational risk, unbudgeted infrastructure cost, and audit findings under frameworks like SOX and PCI-DSS. What are the operational requirements for a GoldenGate replication environment? A production GoldenGate replication topology requires lag and ABEND monitoring, trail file growth management, an on-call rotation, documented runbooks, a patching cadence for GoldenGate Microservices releases, least-privilege credential management, and a defined DR strategy. None of these are optional once replication is intended to run past a project cutover date. Does GoldenGate replication require special security configuration? Yes. Any GoldenGate Extract running in a replication context should operate under a least-privilege account, not a db_owner or SYSDBA-equivalent role inherited from a migration project. Credential aliases should be managed through the GoldenGate Microservices credential store, and access to the GoldenGate environment itself should be audited and controlled like any other production system. What is the difference between GoldenGate Classic and GoldenGate Microservices for these use cases? GoldenGate Classic Architecture is the legacy command-line deployment model. GoldenGate Microservices Architecture is the modern, REST-API-driven, web-managed deployment that Oracle recommends for new implementations. For long-running replication topologies, Microservices is the right choice — it offers better security, easier automation, and a clearer path forward as Oracle continues to invest in the platform. For short migration projects on existing Classic deployments, the upgrade may not be worth it. How do I know if my project is really a migration or a replication? Ask one question: is there a date on which the source system goes away and the GoldenGate environment is torn down? If yes, you're running a migration. If no — or if we'll figure that out later is the answer — you are building a replication practice, whether you intended to or not. Plan accordingly. The Decision Worth Making First GoldenGate will do what you ask it to. The question isn't whether it will work — it will. The question is whether your team understands which job it's actually doing, and whether the operating model behind that job has been thought through before the first parameter file gets written. If you're standing up GoldenGate this year and you aren't sure whether you're running a migration or building a replication practice, that's the conversation worth having now, not after cutover. No pressure, no pitch deck — just a straight conversation about what we're seeing in the field and how it applies to your environment. Contact Us Today About the Author Bobby Curtis is Managing Partner at RheoData, an Oracle ACE Director, and a recognized practitioner in Oracle GoldenGate, Oracle Cloud Infrastructure, and enterprise data replication. He has led GoldenGate migrations and replication implementations for Fortune 500 organizations across financial services, healthcare, and retail.

Oracle GoldenGate migration strategy

Migration vs. Replication with Oracle GoldenGate: One Tool, Two Very Different Jobs

Recent Posts

Migration vs. Replication with Oracle GoldenGate: One Tool, Two Very Different Jobs

Why Run Oracle Workloads on Google Cloud Compute?

Beyond 'db_owner': Securing Your GoldenGate Extracts the Right Way

Posts by Tag

Links