⚠ Preview — Content is not legally binding
Free Forever

Database Migrations. Professional Grade.

Deploy release-based SQL migrations to multiple databases simultaneously. Fully customizable.
Configure. Drop files. Migrate.
Built by database professionals for database professionals. Free forever.

~ RayMigrator
$ RayMigrator Migrate-Up --product MyApp --environment Production --run-mode Migrate
[INF] RayMigrator starting...
[INF] Product: MyApp | Environment: Production
[INF] Repository connected (SQL Server)
[INF] Found 12 pending migrations
[OK] Release 2.1 / 001_create_users.sql (42ms)
[OK] Release 2.1 / 002_create_roles.sql (38ms)
[OK] Release 2.1 / 003_add_permissions.sql (55ms)
[OK] Release 2.2 / 001_alter_users_email.sql (21ms)
... 8 more migrations applied
Migration completed successfully.
12 applied | 0 skipped | 0 failed | 312ms total

Trusted across database platforms

SQL Server
PostgreSQL
MariaDB
MySQL
SQLite

Everything you need for safe migrations

Built for teams that take database integrity seriously. Every feature designed to prevent disasters, not just manage them.

Multi-Target Deployment

Deploy one migration run to multiple targets simultaneously or successively. Sharded DBs, read replicas — one command.

Separate Repository Database

Track all migrations centralized, separate from targets. SQL Server + PostgreSQL + MariaDB in one repository.

Block-Level Progress Tracking

Individual SQL blocks tracked. Know exactly where a migration stopped, not just which file.

Transactional Safety

4 error handling modes: Terminate, Rollback, RollbackErrorOnly, RollbackRelease. Your data stays safe.

Hash Validation

SHA-256 integrity checks with 3 scopes: File, SqlBlocks, or Disabled. Detect unauthorized changes to executed migrations.

Rollback Support

Paired rollback files enable safe downgrades to any previous release. Always have an exit strategy.

Concurrency Protection

Check-and-insert locking pattern prevents concurrent migration runs. Safe for CI/CD pipelines and multi-instance deployments.

3 Run Modes

Migrate applies changes, Simulate shows what would happen, Validate checks integrity — without touching data.

Hierarchical Configuration

6-level raysettings.txt inheritance + 4-file appsettings.json hierarchy. One setup, every environment.

Config Wizard (WebAssembly)

Generate complete configurations in your browser at config.raymigrator.com. Runs 100% locally as WebAssembly — your credentials never leave your PC.

Release-Based Execution

Migrations execute in release order first, then file order within each release. Predictable deployment across environments.

CLI Tool Integration

Execute migrations via sqlcmd, psql, mariadb, mysql, and sqlite3. Run tools directly on the host or inside Docker containers — transparently configured.

How it works

Four simple steps from writing migrations to verified deployments.

1

Write

Write SQL migrations with optional TOML metadata headers

.sql files with optional metadata
2

Configure

Define products, target groups, and environments in appsettings.json + raysettings.txt — or use the Config Wizard

appsettings.json + Config Wizard
3

Run

Execute with CLI — choose your run mode for each deployment

Migrate | Simulate | Validate
4

Track

Block-level progress, checksums, and history archiving in a separate repository DB

SHA-256 verified

Powerful CLI, simple commands

Seven commands cover your entire migration lifecycle — from initial deployment to production rollbacks and orphaned run recovery.

~ Migrate-Up
$ RayMigrator Migrate-Up --product MyApp --environment Production --run-mode Migrate
[INF] Starting Migrate-Up for MyApp (Production)
[INF] Found 5 pending migrations
[OK] Release 2.0 / 001_create_orders.sql (34ms)
[OK] Release 2.0 / 002_create_payments.sql (28ms)
[OK] Release 2.0 / 003_add_payment_index.sql (12ms)
[OK] Release 2.1 / 001_add_order_status.sql (19ms)
[OK] Release 2.1 / 002_add_shipping_table.sql (23ms)
 
Migration completed. 5 applied | 0 failed

Clean, layered architecture

Seven cleanly separated layers following SOLID principles. Each layer has a clear responsibility and minimal coupling.

Console Layer

CLI entry point powered by System.CommandLine

Pipeline Layer

Unified Direct-Mode execution pipeline and command orchestration

Service Layer

Business logic orchestration and migration execution

Core Layer

Domain models, MigrationContext, and options

Infrastructure Layer

Database logging, hierarchical config, and transient error retry

Database Layer

Fully customizable SQL templates, advisory locking, and DAL implementations

Shared Layer

Common types, enums, and exception definitions

Elegant migration file format

TOML metadata headers embedded in SQL files. Your migrations stay valid SQL while carrying rich configuration.

001_create_users.sql
/*
[RayMigrator]
Description = "Create user authentication tables"
Environments = ["*"]
Targets = ["*"]
UseTransaction = true
RunAlways = false
RequireRollbackFile = true
*/
 
CREATE TABLE Users (
Id INT IDENTITY(1,1) PRIMARY KEY,
Username NVARCHAR(100) NOT NULL,
Email NVARCHAR(255) NOT NULL,
CreatedAt DATETIME2 DEFAULT GETUTCDATE()
);

TOML Metadata Block

Wrapped in a SQL comment block. Controls execution behavior, environment targeting, and transaction handling.

Environment Filtering

Target specific environments or use wildcards. Skip dev-only seed data in production.

Standard SQL

The migration body is plain SQL. No proprietary syntax, no XML, no learning curve.

6-Level Settings Inheritance

raysettings.txt cascades from global → product → target group → target → environment → release. Override only what you need.

Environment-Specific Files

Name files like 001_seed.Production.sql to run them only in specific environments. No config needed — just a naming convention.

How RayMigrator compares

See how RayMigrator stacks up against popular migration tools.

FeatureRayMigratorFlywayLiquibaseEF MigrationsFluent MigratorDbUpRound houseEvolve
Atomic Migration and Status Tracking
Concurrency Protection
Multi-Product Repository
Environment Targeting
Environment-Specific SQL
Separate Repository DB
Paired Rollback Files
Code-Free Migration Authoring
Visual Config Wizard
Multi-Target Deployment
Multi-Target Orchestration (Parallel / Sequential)
Multi-Database Support
Block-Level Progress Tracking
3 Run Modes (Migrate/Simulate/Validate)
Config Hierarchy
Database Logging
Orphaned Run Recovery
Env Variable Substitution in SQL
Checksum / Hash Validation
Transparent, external CLI Migration-Tool integration
Pure SQL Files
No Compilation / Build Step
Out-of-Order Migrations
RunAlways Migrations
Baseline Command
Free Forever (no paid tiers)
Supported
Partial / Limited — hover for details
Not supported

Get started in 3 steps

From zero to first migration in under 10 minutes.

1

Download & Install RayMigrator

Download the latest release for your platform from GitHub Releases, then extract and add to your PATH:

PowerShell
# Extract the archive
> Expand-Archive RayMigrator-<version>-win-x64.zip -DestinationPath C:\Tools\RayMigrator
 
# Add to PATH (current user, persistent)
> [Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Tools\RayMigrator", "User")

You can extract to any directory — just make sure it's in your PATH. We recommend /usr/local/bin.

Alternatively, you can clone the repository and build from source.

2

Configure your project or use the Config Wizard

appsettings.json
{
"RayMigrator": {
"Repository": {
"DatabaseType": "SqlServer",
"ConnectionString": "{ENV:REPO_CONNECTION}"
},
"Products": [{
"Alias": "MyApp",
"MigrationFilesRootDirectory": "./Migrations"
}]
}
}
3

Run your first migration

Terminal
$ RayMigrator Migrate-Up --product MyApp --environment Production --run-mode Migrate
[INF] Starting migration...
[OK] 001_init_schema.sql (45ms)
Migration completed successfully.
Concepts

How It All Fits Together

RayMigrator's engine coordinates configuration, migration files, database-specific templates, and an execution layer to run SQL against target databases while tracking every step in the repository.

Migration Files

Release 1 / 001.sqlRelease 1 / 002.sqlRelease 2 / 001.sql

RayMigrator Engine

appsettings.json

ProductsRepositoryTargetGroupsTargets

Migration Service

MigrateUpMigrateDownBaselineValidateInfo

Template Cache

SqlServer .sqlPostgreSQL .sqlMySQL .sqlSQLite .sql

Execution Layer

DALorCLI Tool

Target DB

SQL migrations executed here

Repository (DB)

Migration status persisted here

Legend

Migration Files

Developer-authored SQL files organized into release directories and assigned to target groups. Each file can contain multiple SQL blocks that are executed and tracked individually.

appsettings.json

Central configuration that defines products, target groups with database types and connection strings, repository settings, and migration file directories.

Migration Service

Orchestrates the entire migration workflow: discovers pending files, controls execution order (Release → TargetGroup → Target → File), and coordinates the Template Executor and DAL.

Template Cache

Loads a complete set of fully customizable, parameterized SQL templates per database type at startup. Each template is a SQL blueprint for a repository operation — e.g. creating tables, writing status, or querying migrations.

DAL (Data Access Layer)

Built-in execution via ADO.NET providers. Each database type has its own implementation (SqlServer, PostgreSQL, MySQL, SQLite) with support for transactions, shared connections, and automatic retries on transient errors.

CLI Tool

Optional execution through external, database-specific command-line tools (e.g. sqlcmd, psql, mysql). Configured per file or target group when a native tool is needed beyond ADO.NET capabilities.

Target DB

The target database(s) where SQL migration statements are executed. Each target group can contain multiple targets — ideal for sharded or replicated setups.

Repository (DB)

A separate or shared database where RayMigrator persists migration status: which files have been applied to which target, at what block progress (Pending → Executing → Migrated/Failed). Enables resume on interruption and detection of already-applied migrations.

Configuration

Migration File Layout

RayMigrator organizes migrations per product. Every product defines one or more Target Groups, each containing one or more database targets. Migrations always run against all targets in a group — in parallel or sequentially. Targets in a group must share the same database type.

The appsettings.json configuration defines how migration files are organized on disk and which target databases they run against. Depending on your setup, you can use a single implicit target group or split migrations across multiple groups and targets.

Scenario 1

Single Target Group

When all migration files target a single database, no target group folders are needed. Files are placed directly under release folders and migrate to one database.

MyProduct/
MyProduct
v1.0
001_create_users.sql
002_create_orders.sql
v2.0
001_add_email_column.sql
RayMigrator migrate

MyProduct DB

Tables

UsersOrders

Config Example

appsettings.json
"Products": [{
"Alias": "MyProduct",
...
"TargetGroups": [{
"Targets": [{
"Alias": "MyProduct DB",
"DatabaseType": "SqlServer",
"ConnectionString": "Server=...;Database=MyProductDb;...",
...
Scenario 2

Multiple Target Groups

When migrations target multiple databases, organize files into target group subfolders under each release. Each target group maps to its own database.

MyProduct/
MyProduct
v1.0
Backend
001_create_users.sql
002_create_orders.sql
Frontend
001_create_sessions.sql
v2.0
Backend
001_add_email_column.sql
Frontend
001_create_themes.sql
002_add_theme_colour_column.sql
RayMigrator migrate

Backend DB

Tables

UsersOrders

Frontend DB

Tables

SessionsThemes

Config Example

appsettings.json
"Products": [{
"Alias": "MyProduct",
...
"TargetGroups": [{
"Alias": "Backend",
"Targets": [{
"Alias": "Backend DB",
"DatabaseType": "SqlServer",
"ConnectionString": "Server=...;Database=BackendDb;...",
...
}, {
"Alias": "Frontend",
"Targets": [{
"Alias": "Frontend DB",
"DatabaseType": "PostgreSql",
"ConnectionString": "Host=...;Database=FrontendDb;...",
...
Scenario 3

Multiple Target Groups & Multiple Targets

Target groups can map to multiple database targets. The same migration files are applied to each target within the group — ideal for sharded or replicated setups.

MyProduct/
MyProduct
v1.0
Backend
001_create_users.sql
002_create_orders.sql
Frontend
001_create_sessions.sql
v2.0
Backend
001_add_email_column.sql
Frontend
001_create_themes.sql
002_add_theme_colour_column.sql
RayMigrator migrate

Backend DB 1

Tables

UsersOrders

Backend DB 2

Tables

UsersOrders

Frontend DB

Tables

SessionsThemes

Config Example

appsettings.json
"Products": [{
"Alias": "MyProduct",
...
"TargetGroups": [{
"Alias": "Backend",
"MigrationOrder": "Successively",
...
"Targets": [{
"Alias": "Backend DB 1",
"DatabaseType": "SqlServer",
"ConnectionString": "Server=db1.example.com;...",
...
}, {
"Alias": "Backend DB 2",
"DatabaseType": "SqlServer",
"ConnectionString": "Server=db2.example.com;...",
...
}, ...
}, {
"Alias": "Frontend",
...
"Targets": [{
"Alias": "Frontend DB",
"DatabaseType": "PostgreSql",
"ConnectionString": "Host=...;Database=FrontendDb;...",
...

What's next

RayMigrator is actively developed. Here's what we're working on.

Planned

Oracle Database Support

Full Oracle support with PL/SQL statement handling and Oracle-specific SQL templates.

Planned

RayMigrator Studio

Enterprise-grade management GUI with admin dashboard, migration monitoring, and centralized configuration.

Planned

Config Wizard Optimizations

Enhanced configuration wizard with improved UX, validation, and template management.

AI-Powered

Let AI write your migrations

Paste your schema, describe your change, get production-ready migration files — with correct TOML metadata, rollback scripts, and database-specific SQL.

Your Schema
-- Your schema
CREATE TABLE Users (
    Id INT IDENTITY(1,1) PRIMARY KEY,
    Username NVARCHAR(100) NOT NULL,
    Email NVARCHAR(255) NOT NULL
);

↓ AI generates migration + rollback

RAYCOON AI — Migration Generator
-- Generated by RAYCOON AI for SQL Server
-- Input: "Add audit columns to the Users table"

/*
[RayMigrator]
Description = "Add audit columns to Users table"
Environments = ["*"]
Targets = ["*"]
UseTransaction = true
RunAlways = false
RequireRollbackFile = true
*/

ALTER TABLE Users
ADD CreatedAt DATETIME2 NOT NULL
        DEFAULT GETUTCDATE(),
    UpdatedAt DATETIME2 NULL,
    CreatedBy NVARCHAR(100) NOT NULL
        DEFAULT SYSTEM_USER;
GO

CREATE NONCLUSTERED INDEX IX_Users_CreatedAt
    ON Users(CreatedAt DESC);

The AI Playground understands your existing schema. Paste your CREATE TABLE statements, describe the change you need, and get production-ready migration files with proper TOML metadata, rollback scripts, and database-specific SQL idioms.

Migration GeneratorConfig BuilderSQL TranslatorMigration Reviewer

Coming soon as part of RayMigrator Studio