Migrate Microsoft SQL Server to STACKIT SQLServer Flex

Purpose and scope

Use this runbook to migrate a Microsoft SQL Server database from an existing environment to STACKIT SQLServer Flex. Select one of two paths based on the permitted downtime and the source environment’s replication capabilities:

• S3 backup restore: Best for a planned migration window where the source database can be stopped for backup and final validation.
• Transactional replication: Best when the source database must remain available until a short cutover window. The source environment hosts the Publisher and Distributor; SQLServer Flex is the Subscriber.

This runbook covers database data and schema migration. Assess application compatibility, SQL Server Agent jobs, linked servers, credentials, external integrations, and operational procedures separately before approval.

Owners and decision points

Assign these roles before the migration rehearsal:

• Migration lead: Owns the schedule, evidence, stakeholder communication, and go/no-go decision.
• Source DBA: Owns backup consistency, source performance, Publisher and Distributor configuration, and the source rollback path.
• Target DBA: Owns SQLServer Flex provisioning, access, import or subscription execution, and target validation.
• Application owner: Confirms functional acceptance and approves the write freeze and cutover.

Set an explicit maximum outage, replication-lag threshold, validation dataset, and rollback deadline. Do not begin the final cutover without written agreement on all four.

Choose the migration path

Swipe sideways to see the whole table

Criterion	S3 backup restore	Transactional replication
Suitable downtime	Planned outage for backup, import, and validation	Short final write-freeze window
Initial data load	Full .bak backup in a STACKIT S3 bucket	Restored backup or scripted schema and initial data
Ongoing changes	Not synchronized after the backup	Replicated until cutover
Source requirements	Consistent, unencrypted SQL Server backup	SQL Server Publisher and Distributor, SQL Server Agent, primary keys on replicated tables
Main risk to rehearse	Restore duration and backup completeness	Replication lag, connectivity, and unsupported or omitted objects

Use a backup restore when the data volume and outage window have been tested. Use transactional replication only after proving end-to-end replication in a non-production rehearsal; it is a migration mechanism, not a substitute for an application-level compatibility assessment.

Prerequisites

1. Create the target STACKIT project and SQLServer Flex instance, then confirm administrator access and the target endpoint.
2. Establish and test network connectivity from the source-side Distributor to the SQLServer Flex endpoint when using replication.
3. Inventory databases, schemas, users, SQL Server Agent jobs, linked servers, certificates, encryption, dependencies, and required maintenance tasks.
4. Define the target database name, collation, capacity baseline, backup retention, monitoring, and least-privilege migration accounts.
5. Rehearse the selected path with representative data volume and record duration, throughput, errors, and validation evidence.
6. Schedule the change window, source write freeze, communications, and rollback deadline.

For backup restore, prepare a STACKIT S3 bucket with credentials that permit the restore operation to read the backup files. The documented import supports unencrypted backup files only. Keep credentials out of scripts, tickets, and logs.

Check the product prerequisites below before approving the backup path. They do not replace the rehearsal, application compatibility assessment, or agreed write freeze.

From the STACKIT docsImporting databases from STACKIT S3 buckets › PrerequisitesSource updated 11.03.2026 · copied 06.10.2026

In order to follow the steps described on this page, the following conditions need to be met:

• Your organization has a customer account.
  (See: Create a customer account)

• You have a User Account with the necessary permissions.
  (See: Create a user account)

• You have a Project in your customer account.
  (See: Create a Project)

• You have created a Service Account.
  (See: Create a Service account)

• You have assigned the required project permissions to this service account.
  (See: Assign permissions to a service account)

• You have created an Access Token for this service account.
  (See: Assign authentication token to a service account)

• You have created a SQLServer Flex Instance.
  (See: Create a SQLServer Flex Instance)

• You are connected to the SQLServer Flex Instance.
  (See: Connect to a SQLServer Flex Instances)

• You have previously created a database..
  (See: Create databases in SQLServer Flex instances)

• You previously created a user and assigned the right server role to it.
  (See: Create user)
  (See: Server and project roles and permissions)

• You have a STACKIT S3 bucket.

• You have uploaded the database to be imported as .bak file(s) to the STACKIT S3 bucket
  Note: Only unencrypted backups.

• The database to be imported does not exist on the SQLServer Flex instance (Single and HA) to be imported.

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

Path A: S3 backup restore

1. Prepare and verify the backup

1. Put the source database into the agreed consistency state and create a full backup.
2. Verify that the backup can be read and that its database name, size, and completion time match the migration plan.
3. Ensure the backup is unencrypted and split backup files are fully available when the database uses multiple files.
4. Upload the .bak file or files to the prepared STACKIT S3 bucket and record the exact S3 URIs.

2. Import to SQLServer Flex

1. Confirm that the target database name is unused for the import.
2. Use the documented API or the [msdb].[stackit].[import_database] stored procedure with the target name, S3 URI, and S3 credentials.
3. Wait for the asynchronous restore to complete; do not direct application traffic to the target during the import.
4. Record the restore request, completion time, and any returned operation or trace identifiers.

3. Validate and cut over

1. Compare database object counts, critical table row counts, and a representative set of application queries with the source.
2. Recreate or validate logins, users, permissions, jobs, and application connection settings that are in scope for the target design.
3. Stop source writes, take a final backup if the rehearsal requires it, and repeat the import or final synchronization according to the approved outage plan.
4. Switch application connections only after the application owner accepts the validation evidence.

Path B: Transactional replication

Validate the source editions, versions, primary keys, and SQL Server Agent requirements against the product guidance before configuring the source-side Publisher and Distributor.

From the STACKIT docsHow to implement transactional replication into STACKIT › Planning and PrerequisitesSource updated 24.06.2026 · copied 06.10.2026

Implementing Transactional Replication in Microsoft SQL Server involves several prerequisites and system requirements. Ensuring that your environment meets these requirements is a guarantee for the successful configuration and operation of replication.

System Requirements

Transactional replication is supported in SQL Server Standard, Enterprise, Developer, and Web editions. It’s essential to verify that all participating SQL Server instances (Publisher, Distributor, and Subscribers) are running supported versions and editions.

Cross-version replication is possible, but the Publisher must always be at an equal or higher version compared to the Subscriber.

Preparing the Publisher

• The Publisher database can use either the Full, Bulk-Logged, or Simple recovery model for transactional replication.
• Tables to be replicated must have primary keys defined. Transactional replication relies on primary keys for identifying.
• SQL Server Agent must be activated and started on the distributor.. The SQL Server Agent is responsible for running replication jobs, such as the Snapshot Agent, Log Reader Agent, and Distribution Agent.

Note

The following configuration settings/steps are based on the installation of a replication from an on-premises system to a Microsoft SQL Server instance in the STACKIT cloud. The name of the instance has been shortened for better readability!

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

1. Build the target baseline

1. Create the target database in SQLServer Flex.
2. Initialize it with a restored source backup where possible. If the environments cannot access a shared snapshot location, script the required objects and load the initial data before creating the subscription.
3. Create a dedicated login and database user for the Distributor-to-Subscriber connection, granting only the permissions required by the documented replication setup.
4. Test the connection from the source-side Distributor to SQLServer Flex with the intended credentials.

2. Configure replication from the source

1. Confirm that each table selected for replication has a primary key and that the source SQL Server edition and versions support the chosen topology.
2. Configure the Distributor and distribution database in the source environment, then register the source as Publisher.
3. Enable the source database for publishing, create a transactional publication, and add only the approved articles.
4. Configure SQLServer Flex as a push Subscriber using replication support only when the target was initialized separately.
5. Start the agents and verify that inserts, updates, and deletes reach the Subscriber without errors.

3. Monitor, validate, and cut over

1. Monitor agent health, replication latency, undistributed commands, and source transaction-log growth throughout the synchronization period.
2. Reconcile row counts and critical business totals while replication is running; investigate every mismatch before the cutover.
3. At the approved window, stop application writes to the source and wait until replication lag reaches the agreed threshold, normally zero undistributed changes.
4. Run functional smoke tests against SQLServer Flex, switch application connections, and continue monitoring the target during the stabilization period.

Validation and rollback

Swipe sideways to see the whole table

Checkpoint	Pass criterion	Evidence
Restore or initial load	Target database is online and contains the expected schema and data baseline	Import completion record or initialization log
Data integrity	Agreed row counts, totals, and sample queries match	Signed validation report
Replication, if used	Agents are healthy and final lag is within the agreed threshold	Agent history and lag measurement
Application acceptance	Critical read and write workflows pass on the target	Application-owner approval
Operations readiness	Monitoring, access, backup, and incident ownership are active	Day-1 handover checklist

Abort the cutover and return application traffic to the source if a critical validation fails, the replication backlog cannot be cleared inside the approved window, or target performance prevents agreed service levels. Preserve logs and evidence, diagnose the issue, and repeat only after a new go/no-go decision.

Day-1 operations

For the stabilization period, monitor connectivity failures, database performance, failed jobs, replication status until it is retired, and application error rates. Retain the source database read-only for the agreed fallback period, then decommission replication, source access, and temporary migration credentials through the approved change process.

Product documentation

STACKIT documentation docs.stackit.cloud Import databases from a STACKIT S3 bucket Open the documentation STACKIT documentation docs.stackit.cloud Implement transactional replication into STACKIT Open the documentation