Changing the Wheels While the Car Is Moving: Looking Back at My Oracle-to-Snowflake Migration

At VodafoneZiggo, I worked on a large Oracle-to-Snowflake migration. The Oracle contract was approaching its end date, giving the programme a hard deadline. Yet the system played a critical role in running the business, and freezing all development would have caused significant commercial harm. Some high-priority features and bug fixes still had to enter the database during the migration.

It felt like changing the wheels while the car was moving.

I was brought in halfway through the migration, when the schedule had already turned red. The Oracle contract end date had been extended several times, and the company had decided there could be no further delay.

My assignment was to use my experience across data, infrastructure, Python, and CI/CD automation to accelerate the migration.

The immediate pain: one migration unit took days

The Oracle platform ran on AWS and held hundreds of terabytes of data. Its physical infrastructure and logical databases were managed separately. The programme divided it into dozens of logical database units and migrated them one release at a time.

Each unit required three planes to move together:

• DDL had to be converted and applied in Snowflake;
• existing and changing data had to be copied from Oracle;
• Informatica PowerCenter workflows had to be adapted from Oracle to Snowflake.

Much of this was manual. Engineers executed Snowflake DDL by hand. PowerCenter XML was exported, edited, converted, and imported manually. A migration release could take several days and sometimes close to a week.

Meanwhile, at least 40 PowerCenter developers continued shipping features and fixes. By the time one migration finished, its source baseline could already be stale. A failed release was worse: the team had to reconstruct which SQL had run, which XML was current, and which workflow version was safe to restore.

The root cause: the migration path was not fully automated

The long duration created one source of drift. Production kept changing during every multi-day migration window.

Manual execution created another. Different people could work from different versions, and a partially successful run could leave Git, Oracle, Snowflake, and the PowerCenter server in different states.

The three migration planes also lacked one repeatable release boundary. A successful DDL deployment did not mean the data had caught up. Synchronized data did not mean the PowerCenter interfaces were ready to switch.

There was also a concentration of knowledge in the manual process. The team’s most experienced PowerCenter specialist knew the conversion rules and exceptions and had written some Python scripts, but export, comparison, conversion, import, failure handling, and version tracking were still not one end-to-end path.

The response: automate the complete migration release

I delivered the first automation MVP and pilot in my first week. After Architecture Board review, the team adopted the approach and continued expanding it over the four-month recovery effort.

Turn DDL migration into CI/CD releases

The project already had an early DDL migration mechanism, but engineers still executed SQL manually. I improved it and moved the process into GitLab CI/CD.

For initialisation, Oracle DDL was exported, parsed, checked, and converted into Snowflake syntax. Later releases applied the changes required for the next logical database unit.

Before execution, the pipeline checked whether objects already existed and compared the expected and actual schemas. Unexplained differences failed fast. Releases were idempotent, so a failed run could be repaired and repeated without relying on someone’s notes about which statements had already succeeded.

The Python orchestration covered versioned DDL conversion, execution control, and deployment. The project did not use dbt at the time; this system handled some of the database change-management responsibilities now often associated with modern transformation tooling.

Integrate DMS into the release

The team chose AWS DMS for Full Load and ongoing CDC. This was a team architecture decision. As one of two AWS system administrators, I helped implement the DMS integration, configure and operate the tasks, and bring their checks into CI/CD.

Each logical migration unit had a DMS task. Its initial load usually took four to eight hours and required a high-capacity DMS replication instance. CDC then continued applying Oracle changes while the rest of the release was prepared.

DMS CDC is asynchronous, so cutover still required task-state, latency, and data-reconciliation checks.

Develop once, adapt PowerCenter automatically

We could not freeze PowerCenter development for the duration of the programme. Maintaining Oracle and Snowflake workflows by hand would also have doubled the work and created more drift.

Developers therefore continued working on the Oracle version. I worked with the PowerCenter specialist to encode the conversion rules and exceptions into a standard GitLab pipeline.

When a developer triggered it, the pipeline roughly:

1. exported the latest XML from the PowerCenter server;
2. compared it with the Git-managed version;
3. stopped if it detected drift;
4. converted the workflow for Snowflake;
5. validated and imported the result;
6. recorded the release state in Git.

Re-exporting from the server before conversion prevented an older Git version from overwriting a newer production change. This became the standard PowerCenter migration path.

Switch all three planes through one gate

Automation reduced the non-data steps to hours. With the four-to-eight-hour initial load and CDC keeping the target close to Oracle, one logical database unit could complete its multi-plane migration within a day.

That made it practical to freeze changes for the unit during the migration window. A release could switch only after:

• DDL conversion and schema comparison passed;
• DMS Full Load and CDC reached the required state;
• critical data reconciled;
• PowerCenter showed no unresolved drift;
• the converted workflows imported successfully;
• the business accepted the result.

Any failed gate stopped the switch.

During the stabilisation period, Oracle, the original PowerCenter workflows, and DMS CDC stayed available. If cutover failed, PowerCenter could return to the previous release and the interface could point back to the original path. After repair, the team reran the idempotent release across data, DDL, and ETL.

The result: from several days to less than one

A migration release for one logical database unit fell from several days—sometimes close to a week—to less than one day. The shorter window made a controlled change freeze possible and sharply reduced the time available for production drift to accumulate.

For the PowerCenter developers, feedback that had taken hours or days arrived within minutes. Based on at least 40 developers saving roughly one to two hours per week, plus less manual work for the PowerCenter specialist, I conservatively estimate that the automation removed at least 40 hours of manual work each week. This is an estimate based on participation and previous handling time, not formal time-sheet measurement.

The programme completed before the Oracle contract expired.

That result belonged to the full team: the project manager, AWS administrators, PowerCenter specialist, external Snowflake operations team, business users, and the developers who kept production moving.

My contribution was to improve the existing DDL migration mechanism into an idempotent CI/CD release, turn manual PowerCenter conversion into a drift-aware standard path, and integrate the DMS work into the same controlled migration release.

The lesson I kept is simple: automation changes the migration window. Once a release becomes short enough, production changes can be frozen for that bounded period, and data, DDL, and ETL can switch together with known gates and a known way back.