Lead Database Migration Engineer

This is the sharp end of our Application & Database Modernization pillar. Enterprise customers are moving off Oracle and SQL Server license renewals coming due, stored-procedure layers nobody fully understands onto PostgreSQL and Aurora PostgreSQL. You'll own those heterogeneous migrations end to end: run the AWS DMS and SCT toolchain, then do the part the tools can't rebuild procedural business logic in PL/pgSQL when SCT flags a gap it can't close on its own. You ship the runbook, you run the cutover, you validate the result. When the migration lands, it's yours.

What you'll do?

• Lead end-to-end database migration initiatives: assessment, planning, schema conversion, execution, and post-migration validation.
• Design, configure, and manage AWS DMS and SCT environments and own migration quality, performance, and reliability.
• Author the migration runbooks the cutover lives or dies by: execution procedures, validation checkpoints, rollback plans, operational readiness.
• Perform migration assessments, dependency analysis, compatibility reviews, and migration strategy recommendations.
• Work with infrastructure, application, security, and platform teams to land migration outcomes.
• Drive migration testing: functional validation, performance testing, failover testing, production readiness reviews.
• Provide technical leadership to migration teams and hold the line on AWS migration best practices and governance standards.
• Lead conversion and refactoring of procedural database code Oracle PL/SQL (packages, procedures, functions, triggers, cursors) and SQL Server T-SQL (stored procedures, functions, triggers) into PostgreSQL/Aurora PostgreSQL PL/pgSQL, resolving the semantic and behavioral differences SCT identifies.

What we're looking for?

• 8-12 years of professional experience in database architecture and migration delivery.
• Hands-on expertise in AWS Database Migration Service (DMS) and AWS Schema Conversion Tool (SCT) for enterprise-scale database migrations.
• Deep proficiency in Oracle, SQL Server, PostgreSQL, and Aurora PostgreSQL environments migration planning, execution, and optimization.
• Proven background delivering heterogeneous database migrations across on-premises, cloud, and AWS environments.
• Knowledge of production database operations: backup and restore strategies, parameter tuning, performance optimization, failover testing.
• Skills authoring and executing migration runbooks, validation plans, cutover procedures, rollback strategies, and post-migration stabilization activities.
• Strong understanding of AWS database services, migration best practices, and integration with broader cloud migration programs.
• Experience engaging directly with enterprise customers, architecture teams, and migration stakeholders to drive delivery outcomes.
• Strong hands-on experience converting Oracle PL/SQL and SQL Server T-SQL business logic to PL/pgSQL - exception-handling models, cursor semantics, autonomous transactions, sequences/identity columns, implicit data type conversions, and proprietary built-in packages/functions with no native PostgreSQL equivalent.
• Ability to identify and remediate SCT action items and manual conversion gaps in procedural code (DBMS_* packages, UTL_* utilities, SQL Server system procedures, dynamic SQL, nested/recursive procedure calls) and validate converted logic through functional and regression testing.

You'll be preferred if

• You've tuned production database performance, backup and restore strategy, and failover testing in high-stakes environments.
• You've led migration teams or mentored engineers through complex conversions.
• You bring experience with broader AWS cloud migration programs beyond the database layer.

How we work

Aedeon absorbs the discovery, mapping, and validation grind the 60-70% of hours a traditional consulting engagement of equivalent scope staffs for. Your hours go where the tools stop: conversion judgment, cutover strategy, and the procedural-code gaps only an engineer can close. We commit to fixed delivery dates and absorb the overage cost for delays inside our control, so the runbook you write and the cutover you run carry real weight. You embed with the customer's team and own the outcome not a workstream, the outcome.