Technology we implement

Redgate implementation for database DevOps

Interkey implements Redgate’s tooling for organisations in Saudi Arabia that want database changes delivered the way application changes already are: from version control, through a pipeline, with checks before deployment and a rehearsed reverse.

Migrations under version control Rollback rehearsed

Discuss a Redgate implementation See the database DevOps practice

Redgate

Visit Redgate’s website

In short

What Interkey delivers with Redgate

Redgate makes the tooling Interkey implements when a database delivery practice needs its tools: Flyway for versioned migrations across the mainstream relational platforms, and the SQL Server toolset for comparison, source control and monitoring of an estate built on that engine. Interkey’s work is putting those tools into a pipeline that already exists, retrofitting the change patterns that make automation safe, and handing over a practice the team can run.

This page is not the practice. The practice — why the sequence is not negotiable, why rollback is where the discipline is decided, what finished looks like — is on the database DevOps page, and that page is deliberately indifferent to tooling because a tool does not fix a team whose changes require an outage. This page is what changes when the tooling is Redgate’s: which tool carries which step, and what the implementation actually involves.

The accurate framing is that the tools are the smaller part of the engagement. Flyway can be installed in an afternoon. Getting a schema whose authority is a running server into version control, and getting the change patterns to a state where the pipeline can apply them online, is the work — and it is the same work whichever migration tool applies the result.

Relateddatabase DevOps page

Tool to step

Which tool carries which step of the practice

The five steps are the database DevOps sequence; the middle column is what Redgate’s tooling contributes to each, and the right column is what it cannot do for you. Product names and scope are as of this page’s last update; the vendor’s documentation is the authority on the products.

Step: Establish the truth
What the tooling does: Schema comparison captures what is in each environment; source control tooling puts the SQL Server schema under version control with the drift reported
What stays engineering work: Deciding which differences between environments were deliberate. The tool reports drift; someone has to rule on it.

Step: Fix the change patterns
What the tooling does: Nothing directly. Flyway applies whatever migration it is given, safe or not
What stays engineering work: All of it: expand-then-contract, backfills separated from switches, no destructive change in the same release as the code that stops using the old shape. This is the phase with the real return.

Step: Automate the checks
What the tooling does: Static analysis of migrations in the pipeline for blocking operations, naming and permission changes, where the toolset provides it
What stays engineering work: The rule set: which findings block a deployment in your estate, and which are warnings. A default rule set that blocks nothing is a formality.

Step: Deploy through the pipeline
What the tooling does: Flyway applies versioned migrations in order, records what was applied, and refuses to run out of sequence or against a target whose history does not match
What stays engineering work: The pipeline itself, the promotion path across environments, and the integration with the delivery tooling the application already uses.

Step: Prove the rollback
What the tooling does: Undo migrations can be versioned alongside forward ones and applied by the same mechanism
What stays engineering work: Writing a reverse that is actually safe for data, and exercising it somewhere other than production. A versioned undo that was never run is a plan to discover during an incident whether you had one.

The delivery

From a running server to a versioned schema

Baseline

The production schema captured as the origin, every environment compared to it, and the drift ruled on. There is no reconstructing the history that was never recorded; version one is today.
Tooling into the pipeline

Flyway or the SQL Server toolset wired into the delivery pipeline the application already uses, so a database change is promoted the same way and by the same mechanism as a code change.
Checks that block

The analysis rules set for your estate, with the findings that stop a deployment agreed with the people who will be stopped by them.
Change patterns reworked

The existing schema’s change habits retrofitted to patterns the pipeline can apply online. Slowest step, largest return, and the one the tool cannot do.
Handover

Written standards, a rehearsed rollback, and enough transfer that the practice survives the person who introduced it. Where wanted, the platform is then operated on the managed service.

Readiness

What a Redgate implementation has to be able to show

A tooling implementation is easy to declare and harder to demonstrate. Each of these can be checked by someone who was not involved:

The repository, not a server, is the authority for the schema, and a drift report says which environment disagrees today
Every migration is versioned, applied by the pipeline in order, and recorded, and none reaches production by a console
The analysis rules block at least one class of dangerous change, and the last blocked deployment can be named
Every migration ships with its reverse, and the reverse was run in a lower environment before the forward one reached production
A lower environment can be rebuilt from the repository by someone who has not done it before
Non-production environments hold masked or generated data, and the masking is part of the pipeline rather than a separate favour
The team that owns the database can explain the pipeline without the person who built it in the room

Where it sits

Redgate and the data practice around it

Database delivery tooling is one part of a data practice that also decides which platform an organisation should be on, moves data when that decision changes, and operates the platform afterwards. Redgate’s tooling belongs to the first of those concerns: the changes shipped every week against the platform you already have.

The neighbouring decisions are owned by other pages and handed over rather than answered twice. Whether to stay on the platform is data platform modernisation; moving between platforms is database migration, and the product that moves the records is iblync. Where the estate is a document platform rather than a relational one, the delivery problem changes shape, and the Couchbase page covers that half.

Non-production data

Where the tooling meets data protection

A copy of production is still production data

The ordinary way to get a realistic lower environment is to copy production into it, and for a database holding personal data that is a data-protection decision rather than an engineering convenience. Masking or generating test data is real work and it belongs in the pipeline, so that every rebuilt environment gets it automatically rather than by a favour from the one person who knows the script.

Redgate’s toolset includes data-masking capability for SQL Server estates; where it fits, it is wired into the environment rebuild. Where it does not, the masking is built as pipeline code. Either way the outcome is the same and it is checkable: no lower environment holds unmasked personal data, and the pipeline is what guarantees it.

Scope of this page

Interkey implements Redgate’s tooling inside a database delivery pipeline for organisations in Saudi Arabia, from Riyadh. Flyway and the SQL Server toolset are products of Redgate Software; licensing and the implementation scope are set out in the proposal, and the vendor’s documentation is the authority on what each tool does.

Working together

How work with Redgate begins

Redgate is a technology partner: the tooling is Redgate’s, and putting a database estate under version control, automating its deployment and rehearsing its rollback is done by Interkey’s own engineers. Work begins with the estate as it is — which servers, which schemas change how often, and where a failed deployment hurts most — in a first conversation that picks the pipeline the practice will run through.

Pricing is scoped per programme: the implementation is a fixed piece of work from a running server to a versioned, deployable schema, and Redgate licensing is quoted at the vendor’s terms beside it. Ongoing operation, where wanted, is a written managed-services scope. The practice this belongs to is database DevOps, and the delivery pipeline it plugs into is usually software engineering work.

Buyer questions

What buyers ask us

Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.

Is Redgate an Interkey product?

No. Redgate is a technology Interkey implements, in the same family as Datadog, Couchbase, Docker and Kong on this site. Interkey’s own products are on the products page; the one closest to this topic is iblync, which moves data between platforms rather than delivering changes to one.

Relatedproducts page iblync

Do we have to use Redgate to work with Interkey on database delivery?

No. The practice is tool-agnostic and says so, and an estate already committed to another migration tool is not asked to change it. Redgate’s tooling is what Interkey implements when the estate has no tooling, or when the estate is SQL Server and the comparison and monitoring toolset earns its place.

Relatedpractice

Which databases does this cover?

Flyway covers the mainstream relational platforms; the comparison, source-control and monitoring toolset is SQL Server’s. Exactly which platforms each product supports in which edition changes, and the vendor’s documentation is checked at scoping rather than restated here.

How long does an implementation take?

The baseline and pipeline wiring are a matter of weeks. The change-pattern rework is the long part and is paid down schema by schema rather than in one programme, which means the value arrives incrementally rather than at the end of something that might be cancelled. The practice page says the same thing, because it is a property of the work rather than of the tool.

Relatedpractice page

Discuss a database delivery pipeline

Say which platform, how often the application ships, and how a schema change reaches production today. Whether the tooling is the answer follows from those three.

First name Last name

Company Email Company

Phone number (optional) What are you working on? (optional)

Required field

The Riyadh team reviews your request and a specialist replies on Saudi working days, in Arabic or English. Your details are used only to reply to you. Privacy Notice

Migrations versioned and pipeline-applied

Nothing reaches production by a console
Rollback exercised before it is needed

In a lower environment, every time
Same practice as the application pipeline

Data modelling, administration and DevOps

or See the database DevOps practice

Published by Interkey. Last updated 2026-09-07. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.

Baseline

Tooling into the pipeline

Checks that block

Change patterns reworked

Handover

Discuss a database delivery pipeline