Microsoft SQL Server engineering
SQL Server is almost never a standalone decision. It comes with .NET services, Active Directory, an enterprise agreement and a decade of stored procedures, and the estate around it is what makes the work interesting or difficult.
01Capabilities
Four things that go wrong in a Microsoft estate
This page is the Microsoft-estate corner of our data work. If the estate is not Microsoft, the decision you are making is on our PostgreSQL or MySQL page instead. Almost everything we are asked to do here is one of four things.
- Systems
Line-of-business systems on a Microsoft stack
SQL Server behind .NET services, with Active Directory doing identity and Windows-authenticated connections everywhere. Common in finance and back office, including accounting platforms where the reporting requirement is as fixed as the data model.
- Performance
Tuning against real execution plans, not guesses
Actual plans and wait statistics: parameter sniffing, stale statistics, a hidden type conversion defeating an index, the report that locks a table every morning at nine. Most performance complaints resolve here with no change to the application at all.
- Version
Getting off a version Microsoft no longer patches
And choosing between Azure SQL Database, SQL Managed Instance and SQL Server on a virtual machine. That is a compatibility question before it is a hosting question, and it belongs inside your wider Azure plan.
- Integration
The jobs and packages nobody owns
SSIS packages, Agent jobs and linked servers that run the business and have no tests. Getting that logic somewhere version-controlled and observable is often the highest-value work in the estate. We do it under an ISO 27001:2022 certified information-security management system, alongside our platform integration work.
02Fit
When SQL Server is the answer, and when another store is
SQL Server is an excellent database with an awkward commercial model, and both halves of that matter. Inside a Microsoft estate, arguing about engines is usually a distraction. Outside one, the licence changes the arithmetic. Each row is the call we would make, and three of them link to the page for the database that fits.
| Your situation | What we recommend |
|---|---|
| A Microsoft estate: .NET services, Active Directory, an enterprise agreement you already pay for | Use SQL ServerIdentity, tooling and the skills your team already has outweigh any feature comparison against another engine. |
| A new system, no Microsoft estate, and per-core licensing is real money to you | Different pageOur PostgreSQL page. You give up some tooling polish and take back a licence budget that on a small team funds an engineer. |
| A working PHP application, and somebody has proposed standardising it onto SQL Server | Keep it on MySQLRewriting a healthy data layer to match a corporate standard is cost with no product outcome. Leave it on MySQL. |
| SQL Server on a virtual machine, and nobody whose job is database operations | Managed InstanceSame engine, and patching and backups become somebody else's problem. Compatibility is close enough that the move is usually assessable in days. |
| The pain is reporting: dozens of reports fighting the transactional workload | Move analytics offGet analytics off the operational database, into a read replica or a warehouse, depending on how analytical the questions really are. |
| The licence bill is the stated reason to leave SQL Server entirely | Cost it firstPrice the whole move, including the stored procedures, the packages, the jobs and every report. Sometimes real, and sometimes a saving that arrives three years after the spend. |
Scope
What we own on SQL Server work is the design call and everything downstream of it: whether the schema and the stored-procedure layer can still be changed safely, what the version and hosting decision costs you in compatibility, and whether the integration logic is visible enough for your own people to maintain. unicrew has been building on this stack since 2012, with 100+ senior in-house engineers across six countries. Where a working instance only needs its reports fixed, that is the work we scope.
On a SQL Server estate, a decade of business logic often lives in stored procedures, Agent jobs and SSIS packages. We put that logic under version control before we touch any query plan. Deployments then become repeatable, and your team can roll them back.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Taking on an estate nobody documented
These estates are old, load-bearing and under-described. The order below exists because every shortcut fails in the same place: something scheduled, undocumented and load-bearing turns up on cutover night.
- Find out what actually runsInstances, editions, versions, databases, Agent jobs, packages, linked servers and the reports pointing at them. The scheduled job and the linked server are where the surprises live, because nothing in the application code mentions either.
- Measure before tuning anythingWait statistics, the plan cache and real execution plans for the queries people complain about. Tuning from a symptom rather than a plan is how a database ends up with fifteen indexes that each help one query and slow every write.
- Get the change path under controlSchema and stored procedures in version control with a repeatable deployment. A great many of these estates are still changed by hand in production, and until that stops, nothing else we do is durable.
- Only then take the version and hosting decisionCompatibility assessment first, then a choice between Managed Instance, Azure SQL Database or staying put, with reporting and integration dependencies costed in. Taking this decision before step one is how a migration meets a linked server at 2am.
04Stack
What sits around it in a Microsoft estate
The technologies that turn up in the same estates, each with its own page if that is the decision you are actually making.
05Questions
What people ask before handing over a database
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on a Microsoft estate it is often the sensible arrangement, because your people know which stored procedure the finance close depends on. Our engineers own the design along with the work: an architect outside the delivery team reviews schema and integration changes, migrations go through the same QA practice as our own work, and where you want an outside verdict first we run a quality audit. Team extension is managed teams; an outcome is data engineering.
Look at the estate, not the engines. If you run .NET, authenticate against Active Directory and already hold the licences, SQL Server is cheaper in every sense that matters and the comparison is academic. Starting fresh with per-core licensing as real budget, PostgreSQL gives you most of the capability and hands that line back. We migrate a healthy database for a product reason, never purely because another engine is free.
Managed Instance when you are lifting an existing estate, because it keeps the things applications quietly depend on: cross-database queries, the Agent, and more of the surface area than Azure SQL Database exposes. Azure SQL Database when the workload is a single well-behaved database you are building now and you want the cheaper, more elastic option. Compatibility decides it, so we assess that before discussing price.
Sometimes, and less often than the licence quote suggests. The engine is the easy part. The cost sits in the stored procedures that have to be rewritten, the packages that have to be replaced, the jobs nobody documented and every report pointed at the old schema. We price the whole move first, and recommend it where the saving clears the migration cost inside a sensible horizon.
A scoping call with an engineer. For an existing estate we ask for the version and edition inventory, a list of Agent jobs and packages, and read access to the plan cache where that is possible, because those three tell us more in an hour than a workshop does in a day. What comes back is written: what to fix, what to move, what to keep. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on an estate nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Have a SQL Server estate that has stopped being easy to change?
Tell us what runs on it and where it hurts. You will get an engineer's read on what to fix, what to move and what to keep exactly where it is.