SaaS datacenter migration, as SQL SME
Served as subject-matter expert and lead engineer from the SQL team on the datacenter migration for Expesite, supporting production systems across both public and private cloud throughout the transition.
Senior Systems Engineer | Cloud, Data Platforms & Analytics | DevOps, Migrations & Integrations
Nineteen-plus years across systems administration, infrastructure engineering, and cloud architecture. For the last four I have been the escalation point for Microsoft Premier Support customers — inside other organisations' Azure, SQL Server, and hybrid estates at the moment they fail — and the labs on this page are where I keep the build work current. I work on the parts of a migration that carry real risk: estate discovery, wave planning, cutover, and recovery that has been tested rather than assumed.
What I build
Migrations rarely fail on the technology. They fail on the dependency nobody mapped, the runbook nobody tested, and the cutover window that turned out to be four hours shorter than it needed to be. These are the areas I have spent a career in — and under each one, a lab built and measured against the live platform rather than described.
Azure landing zones, hybrid connectivity, and identity integration designed so the foundation is reproducible rather than a set of portal clicks nobody can repeat.
Moving real estates, not lab samples. Dependency mapping, wave planning, rehost-versus-replatform calls, a pilot wave before the fleet, and a rollback path worth using.
SQL Server upgrades and platform transitions with performance baselines captured before and after, plus the warehouse and analytics layer on top — and the ways it quietly stops being trustworthy.
Release gates that have been tested rather than trusted, baselines declared as data, and idempotence measured against the host — so the second run genuinely changes nothing.
Message pipelines built for the failure at 2am, and DR designed against the SLA, RTO, and RPO actually committed to in customer contracts — with runbooks someone other than the author can execute.
Agents that call real tools and cannot change anything without a person approving it, and low-code products treated as source — with a diff, a review, and a promotion path that says what it will change first.
Selected impact
A shortlist of engagements where the outcome was measurable and the failure mode was public.
Served as subject-matter expert and lead engineer from the SQL team on the datacenter migration for Expesite, supporting production systems across both public and private cloud throughout the transition.
Authored the disaster recovery runbook and method of procedure for Expesite, built against the product's actual SLA, RTO, and RPO commitments rather than aspirational targets — then maintained the plan and ran regular tests against it.
Led the version upgrade for SaaS application Lucernex, alongside building and maintaining multi-layered redundant production environments sized to meet committed SLAs.
Designed, integrated, and implemented a Microsoft Azure hybrid cloud solution enterprise-wide at a bank — running alongside core banking platforms from FIS, Fiserv, Finastra, Banker's Toolbox, and Ellie Mae.
Supported Boeing's SLS program at NASA MAF: VPN and network connectivity, certificate, token, and smart card access, and a fleet-wide replacement of VMware ESX 6.0 hosts with 6.5 across the datacenter.
Ran hosting infrastructure at a peak of roughly 300 domains, 150 websites, and 6,000 mailboxes — and virtualized every last physical server on the network.
Professional experience
From Tier 2 network support to senior escalation engineering for Microsoft Premier customers — with datacenter, banking, aerospace, and SaaS environments in between.
St. Louis, MO · Remote
St. Louis, MO · Remote
New Orleans, LA · Hybrid
Greater New Orleans Area
New Orleans, LA
Concurrent contract engagement alongside the Fidelity Bank role above.
Earlier roles, 2007 to 2017 · select one to expand
What this looks like in practice
Every scenario below links to working code that proves the claim — infrastructure-as-code, tests, and a written account of what the build got wrong before it got it right. Ask the assistant at the bottom of this section if you want to dig into any of them.
A pre-flight assessment that blocks the migration if the schema will not survive it, then parity proven by content checksum rather than row count — because two tables with the same number of rows can still differ. The rollback is restored and verified in a drill, not documented and hoped for.
Almost certainly not, because the clock usually starts when somebody runs the failover command — which excludes detection and decision, the part of an outage that is actually longest. I fail the estate over for real and time it from the first failed write, then count data loss by comparing what the old primary acknowledged against what survived.
Rightly so — it is the one control that can lock you out of the thing you would use to undo it. Policies deploy report-only and get evaluated against a declared matrix of sign-ins before anything is enforced, including a check that the break-glass accounts can still reach a recovery surface. Promotion is something the evaluation has to earn.
The work that decides whether the cutover goes well happens weeks earlier, in the objects: namespaces that cannot be verified, two people holding the same address in different letter case, a disabled leaver holding the sign-in name a new starter needs. I assess that against the live directory, and I check the filter change that silently deletes accounts in the cloud rather than disabling them.
Not by reading role assignments — by signing in as each identity and attempting what it is supposed to be refused. The analysis is written to avoid the false positives that make these reports unreadable: an account excluded from a policy by group membership is not a finding, and neither is the break-glass account that is meant to hold standing privilege.
Then it needs to be tested against the failures that actually happen: the same message delivered twice, a poison message that must not block the queue behind it, two consumers racing for the same work, and a replay path that repairs what it understands and refuses what it does not. At-least-once delivery is a contract, and most code assumes exactly-once.
Labs & projects
Production experience is the record. These are the environments I stand up on my own time to keep the reference architectures current — and to have something to point at rather than describe. Each one is described under the specialty it proves, above; this is the full list, most recently updated first.
Published labs appear here automatically as each build lands on GitHub — every repository ships with its architecture diagram, infrastructure-as-code, and a written summary of what was proven.
Technical depth
Education & honors
Franklin University · 2017
Jones County Junior College · 2007
Get in touch
If you are planning a migration, modernizing a data platform, or trying to find out whether your disaster recovery plan would survive being run — that is the conversation I am good at. Reply time is within one business day, in writing.
Grounded in the resume and the lab write-ups on this page — nothing else.
Answers come from a fixed brief, so treat anything surprising as worth confirming at ziyad@ziyaduqdah.com.