Picture a 30-person distribution business. Dispatch, invoicing and the reports the owner opens every Monday all run against one Cloud SQL instance. It was created back in 2019 on SQL Server 2017, because that was the current version at the time, and nobody has looked at it since. It works fine. That is precisely the problem, because the clock on that version is now public and it has dates attached to it.
What changed, and when
On 14 September 2026, Google published a deprecation entry in the Google Cloud release notes: Cloud SQL for SQL Server 2017 is deprecated. The concrete consequence stated in that entry is that beginning 12 April 2027 you will not be able to create new instances of Cloud SQL for SQL Server 2017. The entry continues with a further step starting in October 2027, so read it in full before you commit a plan to the calendar.
October is not an arbitrary month here. Microsoft's lifecycle page for SQL Server 2017 lists a mainstream end date of 11 October 2022 and an extended end date of 12 October 2027. Cloud SQL's database version policy follows the engine lifecycle: after extended support ends for a major version, Cloud SQL deprecates that version, and an instance still running on a deprecated major version is upgraded automatically to the default major and minor version for the database engine. The same policy says Cloud SQL sends a deprecation notice to project owners at least 12 months before the deprecation date. The September entry is that notice arriving.
Two things follow. You have time, more than a year of it. And the upgrade is going to happen whether you plan it or not, which is the part that decides how the year goes. An upgrade you schedule is a maintenance window on a Saturday night, with the vendor on standby and a tested rollback. An upgrade that arrives on its own is a Monday morning with the phones ringing and nobody sure what changed.
Who this affects among small and mid-sized businesses
In our experience the companies caught by a notice like this are rarely the ones with a database team. They are the ones running a line-of-business Windows application: an ERP, a point of sale, a clinic or workshop system bought from a local vendor, an accounting package that a contractor lifted into Google Cloud years ago and handed over with a connection string and good wishes.
Three groups should look at this in the next few weeks.
- Anyone with a Cloud SQL instance still on SQL Server 2017. One command tells you, and we get to it below.
- Anyone whose application vendor certifies a specific SQL Server version. If the support contract names 2017 and nothing later, the vendor conversation is the long pole, not the upgrade itself. Start it now while it is a planning email rather than an escalation.
- Anyone who rebuilds infrastructure from code. This is the trap people miss. If a Terraform module, a deploy script or a documented recovery runbook pins the 2017 database version, it keeps working until the day you actually need it. After 12 April 2027 that create call fails. A disaster recovery plan that cannot recreate the instance is not a plan, and the worst moment to find out is the moment you are using it.
The good news is that this is ordinary, schedulable work. The bad news is only that it stays ordinary while there is still time on the clock.
What we check on a client project first
Before touching anything, we build the picture. On a typical engagement that is half a day, and it is the half day that prevents the bad Saturday.
Inventory across every project. Companies accumulate projects: one from the original contractor, one from a proof of concept, one somebody made for a test that turned into production. We list instances in all of them:
gcloud sql instances list --project=YOUR_PROJECT_IDThe database version column is what matters. Any instance reporting a SQL Server 2017 edition goes on the list.
What connects to it. For each instance we write down the applications, the reporting tools, the scheduled jobs and the one spreadsheet somebody refreshes with a direct query. That last category is where surprises live.
The vendor support matrix. For each application, which SQL Server versions does the vendor support today, in writing. If the answer takes two weeks to arrive, better to have asked in month one.
Database compatibility level. A database can sit at an old compatibility level inside a newer engine. Knowing the current level for each database tells us whether the query optimiser behaviour changes after the move, and lets us separate the engine upgrade from the compatibility change so that a regression has one obvious cause.
Backups and restores. We confirm automated backups are on, confirm point-in-time recovery is configured, and then confirm somebody has actually restored from them at least once. A backup nobody has tested is a hope, not a rollback.
Infrastructure as code and runbooks. We grep the repositories for pinned 2017 database version strings, because those are the ones that break at creation time next April.
The move, step by step
Cloud SQL supports an in-place major version upgrade for SQL Server. The documentation describes it as the simpler path: you do not migrate data or change application connection strings, and the instance keeps its name, its IP address and its other settings. Under the hood it uses the SQL Server upgrade in-place utility. You need the Cloud SQL Owner or Cloud SQL Admin role to run it.
Here is the order we work in.
- Pick the target version with the vendor, not alone. The temptation is to jump to the newest available version. The right target is the newest version your application vendor supports in writing, which is often a step behind the newest one Google offers.
- Check which targets the instance can actually reach. The available upgrade targets for a given instance come from the Cloud SQL Admin API, through the
instances.getmethod. Confirm the enum you plan to use appears there before you schedule anything. - Rehearse on a clone. This is the step people skip and the step that pays for itself. Clone the instance, upgrade the clone, point a copy of the application at it, and run a real day of work through it: the slow report, the month-end job, the integration that posts invoices. Time the upgrade while you are there, because that number is your maintenance window.
- Take a fresh backup immediately before the real run. Our rollback for a major version upgrade is a restore, so the restore path has to be current and tested, not assumed.
- Run the upgrade in the window. The command patches the instance to the new database version:
gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION \
--project=YOUR_PROJECT_ID- Verify before you go to bed. Application login, a write, a read, the nightly job, the reports. We keep a short checklist per client and work it in the same order every time, because a list beats memory at two in the morning.
- Raise the compatibility level afterwards, as a separate change. Keeping it separate from the engine upgrade means that if a query plan goes strange next week, you know which change to look at. A week apart is usually enough.
- Fix the code and the runbooks the same week. Update the pinned version in Terraform, in the scripts and in the recovery document, then have somebody who did not write it try to follow it.
Cost and risk notes
Worth knowing before anyone panics about a bill: Cloud SQL does not charge for extended support on Microsoft SQL Server, which is different from how Cloud SQL handles MySQL and PostgreSQL. So the pressure here is not a surprise line item on the invoice. The pressure is the automatic upgrade at the end of the policy, which will pick its own moment if you have not picked yours.
Cost can still move for a different reason. If the upgrade is the moment you also change edition or machine size, that changes what the instance costs. Decide those as separate questions and check the current figures on Google's Cloud SQL pricing page rather than trusting a number from a blog post, this one included.
On risk, the honest summary is short. A major version upgrade changes the query optimiser behaviour your application has been running against for years. Most applications do not notice. Some have one report that was quietly depending on an old plan, and it gets slower. That is a tuning job, not a disaster, and it is much easier to handle on a Tuesday after a planned upgrade than in the middle of an unplanned one. Rehearsing on a clone is what turns the first case into the normal case.
One more risk that has nothing to do with the database: the vendor who no longer exists. If the application on top of that instance came from a shop that closed, the upgrade question becomes an application question, and that needs a longer runway than the one the release note gives you. Find out now.
How Guanacos Tech helps
We do this work for small and mid-sized companies across North America and Latin America, in English and Spanish. On a project like this we inventory the instances across every project, get the vendor answers in writing, rehearse the upgrade on a clone, run the real one in a window you choose, and leave you with runbooks that someone else on your team can follow next time. If the vendor answer turns out to be a wall, we tell you that plainly and we plan around it instead of pretending it is fine.
You can see what we do on Google Cloud, or read how we work before you talk to anyone. If you want to put a date on this while it is still a planning exercise, book a call and bring your project list.
Sources
- Google Cloud release notes, 14 September 2026 (Cloud SQL for SQL Server 2017 deprecated)
- Microsoft Lifecycle: SQL Server 2017
- Cloud SQL: Database version policies
- Cloud SQL for SQL Server: Upgrade the database major version in-place
- gcloud sql instances patch (Google Cloud SDK reference)
- Cloud SQL pricing