Microsoft Azure — consulting, migration and operations
Migrate to Azure when it’s the right answer.
Rehosting, replatforming, local Azure , or on-site maintenance. We audit your infrastructure, evaluate the possible migration paths, and then implement the one that aligns with your business applications, data protection requirements, and operating budget —even when the right answer is not to migrate everything.
SQL Server 2016 reached the end of extended support on July 14, 2026. Windows Server 2016 will reach the end of extended support on January 12, 2027. And as of April1, 2026, extended security updates cost the same everywhere: whether Azure, on-site, or through another provider. The argument “migrate to Azure, the patches are free” no longer applies to these two programs.
The Dates That Matter
The question is no longer “Should we go to the cloud ."
It has become: What will you do with the servers that will reach end of support by January 12, 2027, and how much will each month of waiting cost you? Here is the actual timeline, as published by Microsoft—along with the bad news that most pages fail to mention.
April1, 2026
The price of patches is aligned
Microsoft applies a single list price to Extended Security Updates, regardless of the deployment location or purchase channel. Programs already in progress — Windows Server 2012, SQL Server 2014 — remain unchanged.
July 14, 2026
SQL Server 2016 is reaching end of support
Support has ended. No more security patches, no more bug fixes, and no more support unless you subscribe to the extended support program—which is a paid service this time, including in Azure.
January 12, 2027
Windows Server 2016 is being discontinued
The next release. This is still one of the most widely deployed versions in server rooms in French-speaking Switzerland, and unlike in 2012, there are no plans to switch to volume licensing for this program.
Through January 2030
Probation, and Its Pitfall
Patches remain available for three years via Azure Arc, with billing beginning on January 13, 2027. However, the invoice is retroactive to the end-of-support date: signing up later does not cost less.
It is this last point that changes the decision. Postponing the choice saves absolutely nothing: Microsoft charges for the grace period from day one, regardless of the subscription date, and states in black and white that there is no way to avoid it. The only question that remains, then, is: where should these machines be running in 2027?
Find Your PathThe Starting Point
Five paths—and only one is yours.
“Migrating to Azure ” means nothing until you’ve chosen between these five moves. They don’t have the same cost, the same risk, or the same timeline—and two of them aren’t migrations at all.
Repost as is
Virtual machines start up Azure without being modified. The system, application, and version remain the same: this is the fastest and most predictable approach.
When: The hardware is reaching the end of its life cycle, or the end-of-support date is approaching, and the application cannot be modified at this time.
Migrating the infrastructure and applications to a new platform
The database is part of a managed service, and the application is part of a hosting service. There’s no longer an operating system to update, so there’s no end-of-support deadline to worry about in three years.
When: SQL Server 2016 is the real issue, and the database can keep up without breaking the application that uses it.
Application ModernizationAzure Local: Stay at home
The equipment remains on your premises and you retain ownership of it, but it is managed, updated, and billed from Azure. Even when completely disconnected from the public grid.
When: Data cannot leave the building, or the site is too poorly connected to rely on a network connection.
The section Azure LocalBuy time, and use it
You sign up for the extended update program and stay put—but you write down right away what will happen once the grace period ends. It’s not a path forward: it’s time you’ve paid for.
When: a business application crashes, a vendor isn't keeping up, or the organization doesn't have the capacity to carry out the project this year. We'll let you know when that's the case.
Hybrid, managed from a single location
Some leave, some stay, and everything is managed from the same place —inventory, patches, compliance, and logging—whether the machine is Azure, in your data center, or with another hosting provider.
When: the park is too large for a single move, or multiple sites are progressing at different paces. This is the most common scenario.
Our Hybrid page and cloudThe Real Question
Which one is yours?
Four questions, no contact information to provide, and an answer that identifies a path forward and the pitfall that comes with it. Sometimes the answer is “don’t migrate that right now”: that’s written down, too, and that’s what makes the rest credible.
Answer the four questions.
The conclusion is written right here. Nothing is sent, nothing is saved, and there’s no address to provide to read it.
The Movement
Relocate it as-is, then retrofit it.
Your machines are being deployed Azure without any modifications, using the same system and the same application version. We never perform a platform migration under time pressure: changing hosting providers and switching database engines at the same time means there’s no way to tell which of the two operations caused a problem. The platform migration comes later, with no deadline imposed by a vendor.
Migrate the databases to a new platform and move the rest to a new host.
Your real constraint is an end-of-support date, and you have time to make the move once rather than twice. The databases are being migrated to a managed service: there is no longer an operating system to maintain, so there are no more end-of-support dates to deal with. Servers that cannot keep up are being rehosted as-is, and the list of the two categories is determined during the audit.
Azure Local, right here on your premises.
Your data cannot leave your system: the cloud public is kept out, and no one should try to convince you otherwise. The hardware stays on your premises and remains your property, but it is managed, updated, and billed from Azure — even when operating completely offline, as the portal and management services also run on your infrastructure.
Buy a reprieve—and use it.
An application stuck on an outdated version dictates everything else: migrating it as-is is simply shifting the problem, and modernizing it within the remaining timeframe isn’t realistic. So we subscribe to extended security updates, and we’re writing right now about what will happen once the grace period ends —because paying for an extension without a plan in place means you’ll end up paying for it a second time.
This isn't a migration; it’s a fresh start.
Your goal isn't to go to Azure : you’re already there, and the bill is rising faster than usage. This isn’t something you can fix with a tool, but by taking stock of the inventory, the licensed software, the machines left on for no reason, the backups, and the access rights. We take on this type of project for environments we didn’t build —in fact, that’s often what brings us to a client in the first place.
The catch, in your case
You didn't ask your software vendors. This is the number one cause of migration infrastructure, far ahead of technical issues. A publisher who doesn’t support their software in Azure won’t tell you that on their own, and they’ll refuse to step in after the incident. For our hospital project, we contacted every vendor before making any proposals: it was this step that determined the actual timeline, not the other way around.
You’ll discover that Switzerland has one and a half regions. Zurich is open and has three availability zones. Genève, the paired region, is classified as restricted access: it’s available upon request for domestic disaster recovery scenarios and does not offer any availability zones. A “Swiss” recovery plan that assumes Genève is available with a single click turns out to be flawed when it comes time to implement it.
Waiting won't save you any money. Billing for Extended Security Updates is retroactive to the end-of-support date. Subscribing in June 2027 for a Windows Server 2016 license will cost you for the months that have elapsed since January, and Microsoft states that no workaround—such as deactivating, deleting, and then recreating the license, or changing regions or tenants—will allow you to avoid this. Delaying won’t make it any cheaper; it just means you’ll pay for it later, with the added risk.
The part that goes wrong is almost never the calculation. It's the licenses Windows Server and undeclared SQL Server licenses that aren’t reported on a per-machine basis, test environments running 24 hours a day, long-term backups, and outbound traffic. None of these four line items appear in a projection made before the migration, and none of them correct themselves: without someone assigned to review the bill each month, it never goes down.
Your automations will stop, and the error message won't mention it. As of October1, 2025, multi-factor authentication is required on Azure the CLI, Azure PowerShell, infrastructure-as-code tools, and the REST-API for any creation, modification, or deletion. Read operations are still allowed— which explains why a monitoring script might work while a deployment script fails. A deferral was possible until July1, 2026: that window has now closed.
How Your Deadline Changes Things
You still have more than a year left: this is the only situation where you can afford to make the switch once and for all, rather than doing it twice in a hurry. Use this time for the audit and for the publishers, not for waiting—a publisher’s availability won’t happen any faster.
You have less than six months left: the scope must be narrowed down to what is truly required by the deadline, and the rest must be explicitly postponed. A project that tries to do everything within this timeframe ends up completing nothing, and it’s the half that’s started that ends up costing a lot.
The deadline has passed: these machines are now running without a security patch. The first decision isn’t about the path forward— it’s about whether you’ll accept the reprieve now. The retroactive bill is already running, and both your insurance provider and your auditor will ask this question before we do.
What You'll Receive
- The detailed inventory of the equipment fleet and the list of machines that must not be removed
- The monthly operating cost of the target, including licenses and backups
- A Proposed Scope of Work: Scope, Workload, Timeline, Deliverables
This estimate is for informational purposes only: it is calculated based on your four responses, without any knowledge of your specific circumstances. It does not constitute a formal quote. Preparing a quote is free of charge; the audit is the first step in the engagement. We will respond within 24 business hours.
Here, not elsewhere
Switzerland has one and a half regions.
This is the first topic in a Azure , and the previous version of this page cited HIPAA and the European regulation—two laws that do not apply to you. What does apply to you is the Federal Data Protection Act, and the exact location where the data is stored.
Microsoft has been operating two regions Azure in Switzerland since 2019. Data at rest in the Zurich region remains in Switzerland, and this can be verified in Microsoft’s documentation as well as in its contractual commitments. For most organizations in French-speaking Switzerland, this was the answer to the question that had been holding everything up: it is possible to use public- cloud without data leaving the country.
But you have to look at the second row of the table. The two regions are not interchangeable: “Genève ” is not a second Zurich. It serves as a disaster recovery site for the country, located more than two hundred kilometers away—which is precisely its value—and it doesn’t open with a single click.
When it comes to health data, location alone isn’t enough: there are issues of professional confidentiality, data retention periods, and the question of who can technically access what. In our hospital project, this constraint was addressed before technical considerations, and any option that did not meet it was ruled out without further evaluation.
Northern Switzerland
OpenZurich — the production region
- Three availability zones: building high availability without leaving the country
- Data at rest remains in Switzerland
- The broader of the two service catalogs: this is where everything comes together
Western Switzerland
Restricted AccessGenève — the recovery region
- Access must be requested through a support ticket: it does not automatically appear in the list of regions
- No availability zones: it does not replace Zurich; it serves as a backup for it
- Intended for disaster recovery within the country, more than two hundred kilometers away
In practical terms: an “all-Switzerland” recovery plan can be devised, but it’s important to assess it carefully before making any promises. This is the kind of assessment that takes an hour during the planning phase but four weeks if it’s discovered during implementation. We do it during the planning phase.
When the cloud public is excluded
Azure Stay Home: Stay at home without getting stuck.
The cloud public sector isn’t the only answer, and claiming otherwise does no one any favors. Azure Local — the former Azure Stack HCI, renamed in late 2024—is hardware that you own, on your premises, but managed, updated, and billed through Azure.
The difference from a traditional server goes beyond just the hardware: there’s no longer a major version to purchase every three years, and no need to migration to redo every time support ends. There are updates to install regularly, and billing is based on the physical server, covered by the subscription Azure. It’s the same shift in model asExchange Server Subscription Edition for email.
What runs on it: virtual machines Windows and Linux, containers, and virtualized desktops— on your premises, with the latency of your local network. The minimum size of an installation has been reduced to a single node, making it finally feasible for a branch office, a workshop, or a remote site.
And the key factor in organizations with the most constraints: offline operation. The portal, the resource manager, and services such as the key vault can run on your own infrastructure. You maintain your current way of workingAzure without any connection to the public network. This is the same family of solutions as Microsoft 365 Local, where Exchange Server the OS and SharePoint run on the customer’s premises.
The four situations in which we recommend it
- Data It cannot leave the building Regulatory requirements, professional confidentiality, or a client’s or regulator’s requirement. Being located in Switzerland isn’t enough—it has to be on your premises.
- Network The site is poorly connected, or should not rely on a single connection A workshop, a production facility, a clinic: when operations come to a halt if the fiber connection goes down, you don’t run the production application over that fiber connection.
- Latency A machine, a controller, or an instrument must respond locally Industrial control and imaging cannot tolerate the round trip to a data center, even a nearby one.
- Transit You want the operating model before the move Adopt the methodsAzure on your equipment, then move the loads when they’re ready—this way, the move happens without changing tools.
What We Don't Promise: Azure Local is not a cloud cut-down version. The service catalog is more limited, you remain in charge of operations, and the hardware must be on an approved list. We’ll tell you which of the two models is the least bad for your situation— not which one sells best.
The actual cost
What the projection doesn't reveal.
Azure isn't expensive: Azure is calculated. The difference between the two is that no one sends you a bill for a server left running for no reason in your own data center. Here are the five items that account for the difference between the preliminary estimate and the bill for the third month.
| The Position | What the projection shows | What's Happening |
|---|---|---|
| Licenses Windows Server and SQL Server | The calculator displays a price for a virtual machine, which is often exclusive of the license fee—or with the discount already applied. | What Happens: The benefitassociated with the licenses you already own must be reported on a per-machine basis and requires active maintenance coverage. If it is not reported, it is lost; if it is reported incorrectly, it will be disallowed during the audit. This is the first discrepancy—and the easiest one to avoid. |
| Machines That Never Turn Off | Estimates are naturally made in terms of work hours, because that's how we think about the work. | What Happens: The bill is calculated in calendar hours. A test environment that’s left running 24/7 costs four times as much as its actual usage, and this is almost always the first item you’ll find when reviewing an existing bill. |
| Extended Security Updates | "In Azure, patches for older versions are available”—this statement has been true for six years. | What'sHappening: As of April1, 2026, the price is the same everywhere: Azurewhether on-site or from another provider. Windows Server 2016 and SQL Server 2016 are subject to the new policy. Programs already in progress remain unchanged—hence the confusion, even among resellers. |
| Backups and Outgoing Traffic | We measure machine storage, rarely long-term retention, and never outbound traffic. | What Happens:Multi-year data retention and data retrieval are billed separately. This is the expense that comes as a surprise in the third month, when the first annual backup is added to the monthly ones—and it’s calculated in advance, not afterward. |
| Who checks the bill? | Nothing. This item does not appear in any projection because it is not a technical line item. | WhatHappens: Without a specific person assigned to review the bill every month, it never goes down. This isn't a flaw inAzure : it’s the only role in an IT infrastructure cloud that has no on-site equivalent, and it’s the one that’s consistently overlooked when assigning responsibilities. |
During the audit, we calculate the monthly operating cost of the target system —including licenses and backups—and compare it to the actual cost of the existing system, which includes hardware replacement and operating hours. Sometimes the comparison does not look good for Azure for part of the system. We make this clear when it happens: a plan that cannot be justified to a CFO will not survive the first round of budget cuts.
After the switch
The Four Things That Break—and That Nobody Tells You About.
They have nothing to do with the migration : these are platform changes decided by Microsoft, which also affect environments that have been in place for years. They don’t cause any visible outages —they simply cause a script to fail overnight, with an error message that doesn’t explain why.
Since October1, 2025
The second factor is required for the tools
Multifactor authentication is required on Azure the CLI, Azure PowerShellthe mobile app, infrastructure-as-code tools, the RESTfulAPI , and development kits— for any creation, modification, or deletion. Read operations are still allowed, which explains why monitoring continues to function even while a deployment fails.
Here's what we do: We identify all accounts that control resources in the connection logs before making any changes. The grace period was in effect until July1, 2026; it is no longer in effect.
The Main Trap
Your service accounts are not service accounts
A managed identity or a service principal is not subject to this requirement . However, a user account that serves as a service account in a script is subject to it— and this is the most common scenario. There are no exceptions: not for administrative accounts, not for backup accounts, and not for exclusions set in conditional access.
Here’s what we do: we switch these accounts over to workload identities, one by one, checking each time to see who was using them. The directory synchronization account, however, remains unchanged.
In your code
The hard-coded password no longer works
The authentication mechanism that sends a username and password directly—the kind found in old scripts and custom integrations— is, by design, incompatible with two-factor authentication. Microsoft’s authentication libraries have deprecated these calls in all languages, and an application that still uses them throws an exception.
Here's what we do: we look for these calls in the apps and automations that communicate with Azure, and we take them over. This is development work, not operations work: it’s billed separately.
The little thing that ruins a night's sleep
The version of your tools determines the error message
BelowAzure CLI 2.76 orAzure PowerShell 14.3, the tool returns an error instead of prompting for the second factor. The script stops, the output makes no mention of authentication, and you end up spending hours looking for the cause on the wrong end—especially since the administrator’s workstation is often up to date.
Here's what we do: we update the deployment agents and automation servers—not just the workstations. That's where the forgotten versions live.
Our Approach
Nothing is sent until the publisher has responded.
Five steps, in this order, without skipping any. Each one produces something you keep: a document, a configuration, a measurement. The first step is the one most projects skip, and it’s the one that drives everything else.
01
Asset Audit and Feasibility Study
We take inventory of what actually exists: machines, systems and versions, volumes, networks, sites, workstations, backups, and retention requirements. Then we take the step that almost no one else takes: we contact your line-of-business software vendors to obtain written confirmation of whether they support their product in Azure, under what conditions, and how a migration at their end.
It is this response that determines the timeline—not the other way around. Nothing is finalized until then. And sometimes it rules out part of the fleet: this is information that’s better to have now than six months from now.
What We Deliver
- Quantitative inventory: machines, versions, volumes, dependencies, sites
- Each publisher's written statement regarding the platform on which its software runs in Azure
- The list of machines that should not be removed, and why
- The requirements for data preservation and location, as set forth
02
Choosing a Path: The Numbers
We compare the possible scenarios based on just three factors: the monthly cost, the downtime, and how long it takes to complete. The target cost is calculated to include licenses and backups, and then compared to the actual cost of the existing system—including hardware replacement and operating hours.
Everything is documented before the first server is even touched, including the options that were ruled out and the reasons why. An architectural decision whose rationale is unknown is replayed every time there’s a change in personnel, and the second time around, no one remembers the constraint that dictated it.
What We Deliver
- The selected path for each group of machines, and the options that were ruled out
- The monthly operating cost of the target, and a comparison with the current system
- The phased rollout and the windows negotiated with the various departments
- The contingency plan, written before the first shift and not during it
03
Target Construction
We're laying the groundwork: the directory in the cloud, accounts and groups with the necessary permissions, access structured by user profile rather than on a case-by-case basis, the virtual network, and then the servers. For our hospital project, this infrastructure was built from scratch—which is what allowed us to later incorporate additional sites without having to revisit it.
The target is hardened before it is populated. A machine migrated to a poorly configured environment must be restored, and restoration always costs more than the initial configuration. Access is then tested from users' actual workstations at each site, not from an administrative workstation.
What We Deliver
- The directory, groups, and profile-specificpermissions, documented
- The virtual network and the proven connection to your sites
- Workload identities for automations, right from the start
- Testing access from actual workstations, site by site, before any switchover
04
Migration in waves, with the old one still standing
Applications are installed on dates agreed upon with the publishers, who are either present or reachable. We then ask your teams to conduct the tests that only they can perform: verifying that performance meets expectations and that there are no unintended consequences that we wouldn’t be able to detect on our end.
Throughout this process, the existing servers remain online. They are shut down only after you approve it—never before, and never “to free up resources.” This is what makes a switchover a reversible decision.
What We Deliver
- Installations performed in collaboration with the publishers, on agreed-upon dates
- A series of tests conducted by your teams, with the results documented
- Maintaining the previous environment until you provide written approval
- The actual measured flow rate, and the schedule adjusted if the measurement contradicts it
05
Backups, patches, and someone to keep an eye on the bill
A migration doesn’t end with the handover. We implement backups that comply with your retention requirements, centralized updates for the entire fleet, and logging. In the hospital project, it was this last step that enabled the client to permanently delegate security and patching responsibilities.
And we’re calling out what no one else does: who actually reviews the invoice every month? Whether it’s you, your usual service provider, or us—as part of a service contract—but someone has to do it. An invoice that cloud that no one reads never gets paid.
What We Deliver
- Backups that comply with your retention requirements and have been tested for restoration
- Centralized updates for the entire fleet, including on-site units
- A monthly review of the bill, with a designated person to handle it
- Knowledge Transfer: Your Administrators Need to Know How to Stay on Target
Our involvement can cover the entire process or just one step —such as the audit and cost estimation alone, for example, when your team will carry out the work itself. The decision is made during the scoping phase, based on your constraints and internal capabilities, not on our usual practices.
Let's talk about your fleet
What is your situation?
Seven reasons to open this file. If any of them sound familiar, you've come to the right place—and we've seen this happen before.
Your servers will reach the end of support in the coming months
Windows Server 2016, SQL Server 2016, or even older versions. You have to decide between migrating and paying the penalty, and no one has provided you with cost estimates for either option.
Your equipment is reaching the end of its useful life, or you're leaving a room
The question is no longer “should we renew?” but “should we renew?” A capital investment is a five-year commitment: it should be evaluated before signing the contract.
Your teams aren't performing well when working remotely
Business applications that are accessible from outside the company offer only a limited version, or slow down as soon as everyone logs in at the same time.
Your data is sensitive or subject to regulations
Healthcare, finance, the public sector, contractually governed customer data: location, storage, and access must be addressed before technical considerations, not after.
Your bill Azure is rising faster than your usage
You're already there, and the discrepancy with the initial projection can no longer be explained. It's not a problem with the tool; it's a governance issue—and it's getting worse.
A business application is blocking you
A text editor that doesn't keep up, a version you can't exit, a bot connected to the server. It's the constraint that decides, and it's the first thing you notice.
Are you looking for a team to lead your project, or to strengthen your own team?
On a fixed-price basis for a defined scope of work, as reinforcement for your teams under your leadership, or as Level 2 and 3 support after the system goes live.
Why Choose Us
We make the most of both worlds.
Lambert Consulting has been Microsoft Solutions Partner and has been deploying Microsoft infrastructure in French-speaking Switzerland since the earliest versions of Windows Server. We build on Azure and still operate server rooms —so we have no commercial reason to promote one over the other.
migration Our most recent project on this topic is an infrastructure-to- Azure , in the healthcare sector, where Swiss regulations governing patient data dictated the architecture before any technical choices were made. It has been published, along with the methodology and results.
280+
Websites managed through a single portal, on a platform that we designed and developed on Azure
30 years
Microsoft Infrastructure Projects in French-Speaking Switzerland: From the First Server to the Tenant Azure
2018
Federal Authorization for Staffing Services: We can assign an engineer to your company
What's included
- A single point of contact for servers, the directory, workstations, and email. The four go hand in hand; it makes sense for a single company to manage them all.
- We’re reaching out to your publishers. This is the most thankless stage of an infrastructure project—and the one that determines the actual timeline.
- On-site teams: Renens, Sion, Châtel-Saint-Denis. No one opens a support ticket from the other side of the world on the night of the switchover.
- We take over projects we didn't build. Level 2 and 3 support for environments Azure set up by someone else: this is a common request we receive.
- We also know how to say no. When part of the fleet costs more in Azure, it’s specified in the quote—not something you find out in the third month.
Frequently Asked Questions
What we're asked to do before we begin.
The seven questions that come up on every first date. The answers are intentionally specific: a vague answer at this stage doesn't help anyone.
Should we migrate everything to Azure ?
No, and it’s rarely the best option. In almost all the parks we audit, there are machines for which Azure cost more than the existing ones, or whose manufacturer does not support relocation. These machines stay where they are and are managed along with the others.
The actual migration is almost always partial. What matters is that the boundary be chosen based on the numbers and documented, rather than determined by what was easiest to migrate first.
Can our data remain in Switzerland?
Yes, for production: data at rest in the Zurich region remains in Switzerland, and this region has three availability zones—so it's possible to build a high-availability system there without leaving the country.
The key difference lies in disaster recovery. The region paired with Genève is classified as “restricted access”: it is available upon request and does not provide availability zones. A fully Swiss disaster recovery plan is feasible, but this is verified during the scoping phase —not when the plan is being developed.
How much does it really cost per month?
It’s impossible to say without an inventory, and anyone who gives you a figure before the audit is giving you a false figure. What we can say is where the gap is widening: unreported licenses on a per-machine basis, systems left on 24/7, long backup retention periods, and outbound traffic.
During the audit, we calculate the monthly cost of the target solution—including licenses and backups—and compare it to the actual cost of the existing system, which includes hardware replacement and operating hours. It is this comparison that matters, not the listed price of a virtual machine.
What if our publisher doesn't support its software in Azure ?
So we don't migrate it, and we know that before we commit to anything. That is precisely why we write to the publishers during the audit and keep a record of their response: a publisher who hasn't promised anything will refuse to intervene after the incident—and they'll be right to do so.
In this case, there are two options: keep this application on-premises while the rest are migrated, or opt for an extension of extended support until the vendor catches up. Both are reasonable; improvising is not.
Windows Server 2016: Do we migrate, or do we pay for the reprieve?
It depends on what’s running on it, and the pricing changed on April1, 2026. Before that date, migrating to Azure gave you access to patches for older versions at no extra cost: that was a powerful financial incentive. Since then, the price has been the same everywhere —whether Azure, on-premises, or with another provider—for new software, including Windows Server 2016 and SQL Server 2016.
The key takeaway: Billing for the grace period is retroactive to the end-of-support date. Signing up later doesn’t cost any less, and Microsoft states that there’s no way to avoid it. There’s therefore no longer any financial benefit to waiting—only the risk remains.
Can we go back if it doesn't work out?
Yes, on one condition: that the old environment is still up and running. That’s why we never shut it down without your written approval, even when the migration migration went smoothly and the resource appears to be idle for no reason.
This means a few weeks of dual operation, and that’s the price of a reversible decision. As part of our hospital contract, the on-site servers remained online throughout the client’s testing campaign and were shut down only after the client approved the results.
Are you going to keep running it, or are you leaving?
Both options are possible, and the choice is yours. We can continue under a service contract, which includes Level 2 and 3 support, monthly invoice reviews, and patch management. Alternatively, we can transfer these respons ibilities to your teams or your usual service provider, along with all relevant documentation.
What we don't do is build an environment that no one but us knows how to maintain. We don't intend to stay; we want to ensure that your administrators will know how to maintain the target after we're gone.
About the Infrastructure
What a project Azure always touches.
Infrastructure doesn't stand alone. Here are the other building blocks we're laying—and that projects Azure almost always end up intersecting with.
Let's talk about it
Let's start with the inventory.
Describe your portfolio in a few lines: the versions, the number of sites, and what’s urgent. We’ll tell you what similar projects we’ve handled and how we could assist you. The proposal is free— it outlinesthe scope, workload, timeline, and deliverables—with no obligation on your part. The audit is the first step of the engagement—that’s where the work begins.