At S&P Global Market Intelligence I helped migrate on-premise SQL Server databases to Azure SQL PaaS. Our team moved between 10 and 50 databases to Azure SQL Managed Instance. The headline result was a reduction in infrastructure costs of about 25%. The more important result was that the people using those databases barely noticed it happened.

Here’s what I learned about doing a migration like that well.

1. Inventory before you plan

Before choosing a target, list everything that touches the database: ETL jobs, reports, linked servers, SQL Agent jobs, cross-database queries, CLR assemblies. PaaS options don’t support every on-prem feature in the same way, and you want to find the gaps on a spreadsheet, not in production.

Microsoft’s Data Migration Assistant and Azure Migrate help here, but they don’t know about the Excel workbook someone in finance refreshes every Monday. Talk to users.

2. Pick the right PaaS flavour

Azure SQL Database and Azure SQL Managed Instance trade compatibility against simplicity. Managed Instance keeps more instance-level features (Agent jobs, cross-database queries), so it suits lift-and-shift. Single databases are simpler and can be cheaper, but may need refactoring. Decide per workload, not per estate. We went with Managed Instance, which kept most instance-level features in place and meant fewer changes to existing code.

3. Right-size, don’t copy

Most of the savings came from not paying for capacity we didn’t use. On-prem servers are sized for peak load plus growth plus fear. In the cloud you can measure actual usage and scale. Look at real CPU, memory and IO over several weeks before choosing service tiers.

4. Migrate in waves

Start with low-risk databases: development, reporting copies, internal tools. Each wave teaches you something about networking, permissions or performance that makes the next wave smoother.

5. Test the boring things

Performance gets attention. In our migration, the real problems came from elsewhere:

• Connection strings hard-coded in old applications and reports
• SSIS packages and SQL Agent jobs that needed reworking to run against Azure
• Jobs that relied on local file paths on the old servers

Also worth checking: time zone and collation differences, firewall rules and private endpoints.

6. Define “done” with the users

A migration isn’t finished when the data moves. It’s finished when every report, job and application works as before and the old servers are switched off. Agree that checklist with stakeholders up front.

The takeaway

Cloud migration savings come mostly from right-sizing and retiring infrastructure. Keeping users happy comes from inventory, testing and communication. Neither is glamorous, and both matter more than the migration tooling.

In 2015 I finished a Bachelor of Computer Applications in Gujarat and took my first job doing SEO keyword research. Ten years later I hold an MSc in Data Analytics from National College of Ireland, I’ve built data platforms for a global financial information company, and I work on platform integrity operations in Dublin.

This is the first post in a series where I’ll write about what I’ve learned along the way: data engineering, generative AI, and the less glamorous work of keeping online platforms safe.

The early years: cleaning data by hand

My first data role was at Bright Info Solutions in Ahmedabad. Most of the work was unglamorous: pulling data with SQL, cleaning it in Excel and Python, building weekly reports. It taught me the lesson every analyst learns early. Most of the job is making data trustworthy before anyone looks at a chart.

Building platforms at scale

From 2019 to 2024 I worked at S&P Global Market Intelligence as a data analyst and ETL developer. I built SSIS pipelines over multi-million-record financial datasets, designed data models for analytics, and helped migrate on-premise SQL Server databases to Azure SQL PaaS. That migration cut infrastructure costs by about 25%.

What I took from those years: good data engineering is invisible. When it works, nobody notices. When it breaks, everyone does.

Starting again in Ireland

In 2024 I moved to Dublin for a master’s. Going back to study after nine years of industry work was humbling. Modules in machine learning, deep learning and generative AI showed me how fast the field had moved. My dissertation combined knowledge graphs and prompt engineering, and my main project, SkillBot, paired a fine-tuned GPT-3.5 model with a 2.3-million-triple knowledge graph using retrieval-augmented generation.

Where I am now

Today I work in platform integrity, analysing complex escalations with AI-assisted tools. It sits where my two interests meet: data and AI used to make platforms safer.

Why write in public?

Three reasons:

1. Writing forces clarity. If I can’t explain something simply, I don’t understand it yet.
2. Dublin is one of the world’s great tech hubs. I want to contribute to its data and AI community, not just work in it.
3. Accountability. Publishing every week keeps me learning.

Over the coming months I’ll post about Azure migrations, RAG evaluation, knowledge graphs, content moderation metrics, and the career lessons in between. If any of that interests you, follow along. I’d love to hear what you’re working on too.