Microsoft SQL Server · Azure

SQL Server in Azure:
the right platform, a verified migration

Your application should run reliably in Azure, including under high load, at month-end close, and after maintenance. For that, the platform, the database, and the application have to fit together.

PSG supports you with the decision, the planning, and the implementation of a SQL Server migration to Azure. We look at your existing application, its dependencies, and the actual load. With your team, we then develop a suitable target design and, after the move, verify whether it meets the agreed requirements.

Do you already run SQL Server in Azure? We also examine existing environments when response times, stability, or resource consumption raise questions.

Discuss your Azure project → Investigate performance after the migration

migration · dependenciesStructural model

Starting points

Where do you stand right now?

A move to Azure is under discussion

A version change is due, hardware has to be replaced, or the company strategy calls for Azure. Now you need a reliable answer: Which SQL platform fits the application, which adaptations are required, and what does the decision mean for your operations?

We help you organize requirements and options. That includes factoring your existing operations and possible hybrid solutions into the assessment.

To the platform decision →

⇄

The target is chosen, and the migration has to work

The databases are only one part of the move. Applications, interfaces, jobs, permissions, and operating procedures also have to work afterward. Especially in systems that have grown over time, important dependencies lie outside the individual database.

We support you in making these dependencies visible, testing the migration, and coordinating the cutover, the acceptance, and the fallback path with everyone involved.

To the dependencies →

⏱

The application runs in Azure and falls short of expectations

Individual operations take longer, peak load is hard to manage, or the chosen sizing seems disproportionately large. In that case, we examine how the application, queries, and platform interact: What consumes resources, where does it spend time waiting, and which change improves the affected business transaction?

To the guide on performance after the migration →

Results

What you get from working with us

The engagement is shaped by your starting point. Depending on the question, we work with you to produce the following results.

IllustrativeFour possible results

Result 01Platform selection

Assumption: The application uses instance-level features.
still to be checked: Vendor approval for the target

More ↓ Result 02Dependencies

Assumption: A nightly import reads files from a share.
still to be checked: File access in the chosen target

More ↓ Result 03Sizing

Assumption: Month-end close determines the peak load.
still to be checked: Measurement data from a close period

More ↓ Result 04Migration & acceptance

Assumption: The cutover takes place in a maintenance window.
still to be checked: Fallback path after the first writes at the target

More ↓

The specific engagement determines which results we work out together. Sample fields: Assumptions and open checks are examples, not results from a customer project.

Result 01

A traceable platform decision

SQL Server on an Azure VM, Azure SQL Managed Instance, and Azure SQL Database differ in features, in the control you have, and in operational tasks. We compare the suitable options against your requirements and state what has already been clarified and what still has to be tested.

You receive a reasoned selection with the consequences for the application, operations, and further work. The three platforms compared.

Structural modelThree targets, differing amounts of design on your side

VMSQL Server on an Azure VM

Application
Databases and queries
SQL instance
Engine operations
Operating system
Infrastructure

MIAzure SQL Managed Instance

Application
Databases and queries
SQL instance
Engine operations
Operating system
Infrastructure

DBAzure SQL Database

Application
Databases and queries
SQL instance
Engine operations
Operating system
Infrastructure

Your team designsMicrosoft operates the platform

Which layers your team designs itself is what sets the three targets apart. What this means for features, operations, and migration: Read the platform comparison →

Result 02

Clarity about dependencies and adaptations

Which applications access which databases? Which jobs, logins, file access, and connections to other systems are involved? What does the software vendor support for the chosen target?

From the inventory comes a working basis: components that can be carried over, necessary changes, owners, and open checks. This makes assumptions verifiable before the move to production.

Structural modelAn application moves with its dependencies

Today · Your environment Planned Azure target

ApplicationUsers and services

Calls

Jobsscheduled processes

Processing

IdentitiesLogins and permissions

Permissions

FilesImports, exports, file locations

Processing

Interfacesother systems

Calls

DatabaseSQL Server, today

Migration

Applicationcheckcarry over or adapt

Jobscheckcarry over or adapt

Identitiescheckcarry over or adapt

Filescheckcarry over or adapt

Interfacescheckcarry over or adapt

A database is connected to an application, jobs, identities, files, and interfaces. For the new target, these dependencies are checked individually. Whether a part falls under carry over or adapt becomes clear only in the project check; the model does not rate any component in advance.

Migration involves data, applications, and the processes in between.

Result 03

Sizing that fits the load

We look at CPU, memory, data access, and write load in relation to one another over time. Day-to-day business, peak loads, and periodic processing belong in the same assessment. The number of existing processor cores alone is not sufficient for sizing the target.

The recommendation states its measurement basis and assumptions. These include performance headroom, growth, and the question of which requirements can be influenced by changes to queries or the application.

Structural modelDeriving sizing from the load profile

Headroom

Import

Day-to-day business

Average

schematic · no measured values

CPUCompute time of the operations
MemoryWorking memory for data
Data accessReading and writing on the data storage
LogWrite load on the transaction log

Day-to-day business, import, and close represent different load situations for which CPU, memory, data access, and log have to be assessed. The average alone does not fully describe the requirements.

Sizing must also support the relevant peaks and processing windows. Schematic: Heights and widths only illustrate; they are not measured values.

Result 04

A coordinated process with acceptance

We plan with your team how the migration can be verified: through a test migration, defined business transactions, load tests within the agreed scope, and concrete criteria for approval. For the cutover, responsibilities, time windows, and the handling of unexpected results are defined.

An important distinction applies to the fallback path: Once new production data has been written at the target, a return must also account for those changes. We clarify this question before the move.

IllustrativeAcceptance of a business transaction

Business transaction “Save order”Acceptance sheet · open template

Check item	Requirement	Verification	Result
Business correctnessDoes the operation deliver the same business results?	Agree on target	Assign evidence	open
Response timeHow fast must the operation be, even under load?	Agree on target	Assign evidence	open
Successful completionsAre the operations completed in full?	Agree on target	Assign evidence	open
ErrorsWhich errors occur, and how are they handled?	Agree on target	Assign evidence	open
Operational evidenceDo backups, jobs, and monitoring run as agreed?	Agree on target	Assign evidence	open

Acceptance checks whether the new environment fulfills the agreed tasks. Open template: We define targets and evidence for your business transactions.

Cutover and fallback path in the project sequence: From target design to acceptance ↓

Approach

How we proceed

Structural modelFrom target design to acceptance

1RequirementsResultverifiable criteria for technology and business processes
2Current stateResultdatabases, dependencies, and load; missing measurement data identified
3Target reviewResultreviewed target options and a suitable migration path
4Test and cutoverResulttested test migration, cutover according to the agreed plan
5AcceptanceResultcomparison with the agreed criteria, handover to operations

At step 4: Cutover and fallback path

Fallback path before writes at the target

No new production data has been created at the target yet. The fallback path follows the procedure agreed beforehand; the prerequisite is a source state preserved unchanged.

First production writes at the target

Fallback with new target data

A return must also account for the changes written at the target. How, we clarify before the move.

Approval and fallback path are agreed before the production cutover. Five project phases with verification results. After new writes at the target, the fallback path must also account for that data.

01
Clarify requirements and success criteria
Which operations must be how fast? How much downtime and how much data loss are tolerable? What can your team operate in the long term? And what should become better economically or organizationally through the migration?
We agree on criteria that can be verified at the end. Besides the technology, these include the business processes of your users.
02
Understand the existing environment and workload
We look at databases, instance features, applications, and operational dependencies. Existing measurement data helps identify typical load and critical time windows. Where important data is missing, we define the necessary data collection together with you.
03
Review the target design and migration path
From the requirements and the existing environment, we derive suitable target options. We review required features, network paths, availability, and sizing. The migration path depends on the source, the target, the data volume, and the permissible interruption.
04
Test, implement, and cut over
A test migration shows whether data and dependencies arrive as intended. Together with the operations team, development, and, where applicable, the software vendor, we review the relevant processes. Implementation then follows the agreed plan.
05
Verify the effect and hand over to operations
After the move, we compare against the agreed criteria: response times, completed operations, errors, resource consumption, and operational procedures. Documentation and knowledge transfer help your team get to know the new environment and keep operating it.

Cost-effectiveness

Considering performance and cost-effectiveness together

In Azure, resources can be provisioned differently than in your own data center. How large a configuration your application needs still depends on the work it performs.

For that reason, we look at the platform and the workload together. A costly query, many small database calls, or long transactions can determine resource demand and response times. A larger configuration can help; likewise, a targeted change to data access or the application may be the right step.

We don't resell SQL Server licenses, and we don't need to reach any Azure revenue to keep a partner status. For that reason, we advise independently on platform selection, edition, and core configuration, with no interest of our own in selling licenses or cloud services. The cost assessment covers the assumptions of the specific target design: required performance, storage, availability, data transfer, and operations.

A saving is reliable only when a change also improves the usage or configuration that is actually paid for. Less CPU work alone is not yet a smaller bill.

Structural modelChecking effect and bill separately

1 · AssumptionAssumed: query or data access improvedless CPU work, shorter response times
2 · Paid usage or configurationCase Astays unchangedCase Bis sized smaller or used less
3 · ResultCase ATechnical effectFaster operations or more headroom; the bill stays the same.Case BPossible savingThe change also improves the paid usage or configuration; only the billing shows the amount.

Less effort and a lower bill are checked separately.

Collaboration

With your team and your partners

You know your application and are responsible for how it is used. Your operations team, development, your hosting partner, or the software vendor bring further parts of the overall picture. We complement this collaboration with the SQL Server depth it needs.

Our support can begin with a second opinion, accompany a migration phase, or address a specific performance question. We agree on the scope and responsibilities to suit the project. For ongoing support, we draw on our existing offerings for SQL Server DBA services and performance engineering, as far as they fit your environment and task.

Structural modelParticipants and their tasks

YouApplication and its use Operations teamongoing operations DevelopmentCode and data access

Your Azure projectScope and responsibilities: to be defined in the project

Hosting partnerPlatform and network Software vendorApprovals PSGSQL Server depth

Starting points, for example: second opinion migration phase performance question

Responsibilities are defined for your project.

Answered briefly

Frequently asked questions

Do we have to rework the application for a migration?

That depends on the features in use and on the target. SQL Server on an Azure VM offers a different framework than a managed database service. We examine the actual dependencies and vendor approvals before any necessary changes are assessed.

Which Azure SQL platform is the right one?

The decision follows from the application, operations, and requirements. Our platform comparison explains the differences and helps you put together the key questions for your environment.

Can you review an existing concept?

Yes. For a review, we first clarify the open questions and then examine assumptions, architecture, and the planned evidence. This yields confirmed points, risks, and concrete next checks.

How much downtime do we need to plan for?

The possible interruption depends on the migration path and the applications involved. We plan and test the procedure for your starting point. Connection recovery, follow-on processing, and the business approval also belong in the time window.

The application has already been migrated and is slow now. Where do we start?

With a specific affected operation and a clearly bounded period. We compare application time, database work, and platform metrics, and derive the next check from that. The guide to performance after the migration shows this approach.

Which next step helps your project?

Are you planning a migration, do you need a second opinion, or do you want to improve an existing Azure SQL environment? Describe your starting point and the question you want to answer. Helpful details are your current system, the planned or existing Azure target, and the specific trigger.

In the first conversation, we clarify which investigation or support makes sense.

Discuss your Azure project →Email info@psg.de

Phone+49 40 39 88 28 75Emailinfo@psg.deAddressPSG Projekt Service GmbH
Neuer Wall 80, 20354 Hamburg

SQL Server in Azure:the right platform, a verified migration