Cygenix Help Guide

Cygenix is an AI-powered database migration platform. It connects to SQL Server, Azure SQL, PostgreSQL and file sources, maps columns using Claude AI, applies value translations, validates results, and delivers professional reports — all from the browser. The full support matrix lists every source, target and combination, and is generated from the product itself rather than written by hand.

Mapper

Target-driven column mapping with AI, fixed values, Was/Is rules and one-to-many support.

Validation

Add any table as a validation source. Pick the SQL column, report columns and run connection.

Typical workflow

The recommended migration sequence in Cygenix:

Set up Project Settings

Enter project name, start and completion dates, source and target systems. The completion date drives the countdown in the summary stats bar.

Run pre-migration validation

Add your validation tables in the Validation page. Run scripts against the source database to identify data quality issues before migrating.

Map tables using the Mapper

Use Simple Map for single-table migrations or One-to-Many for complex transformations. AI maps columns automatically — override as needed, add fixed values and Was/Is rules.

Build and run a Conversion Project

Combine multiple mapping jobs and custom SQL scripts into a sequenced project. Run in one click with live status per step.

Run post-migration validation

Re-run validation scripts against the target database to confirm data migrated correctly.

Export the Conversion Report

Download a client-ready Excel report with summary, migration results, column mapping, Was/Is applied and execution log.

What Cygenix supports

This table is generated from the product's capability manifest, so it is what the software actually does rather than what it was described as doing when this page was last written by hand.

Sources

Source	Status	Notes
SQL Server 2012+	Available	On-premises, Azure VM, AWS RDS, Google Cloud SQL.
Azure SQL Database	Available
Azure SQL Managed Instance	Beta	Connects and migrates as SQL Server. Not yet proven across enough estates to call it GA.
PostgreSQL	Available	Self-hosted, RDS, Aurora, Azure Database, Cloud SQL, Supabase, Neon.
CSV, Excel and text	Available	.csv, .xlsx, .tsv, .txt — multi-sheet workbooks handled.
Azure Blob Storage	Available	Files in a container you supply a SAS for.
MySQL / MariaDB	Planned	No driver is present. Sold on the pricing page until 25 Aug 2026; withdrawn until it ships.

Targets

Target	Status	Notes
SQL Server 2012+	Available
Azure SQL Database	Available
Azure SQL Managed Instance	Beta
PostgreSQL	Available
MySQL / MariaDB	Planned	No driver is present.

Source and target combinations

A combination absent from this table has not been assessed. Cygenix refuses it rather than assuming it works.

From	To	Status	Server-level objects
SQL Server	SQL Server	Available	Moves as-is
SQL Server	Azure SQL Database	Available	Needs an equivalent
SQL Server	Azure SQL Managed Instance	Beta	Moves as-is
SQL Server	PostgreSQL	Beta	Not possible
PostgreSQL	PostgreSQL	Available	Not possible
PostgreSQL	SQL Server	Beta	Not possible
PostgreSQL	Azure SQL Database	Beta	Not possible
CSV, Excel and text	SQL Server	Available	—
CSV, Excel and text	Azure SQL Database	Available	—
CSV, Excel and text	PostgreSQL	Available	—
Azure Blob Storage	SQL Server	Available	—
Azure Blob Storage	Azure SQL Database	Available	—

Server-level objects, by target

Logins, Agent jobs, SSIS projects and linked servers live at the server level, and target platforms differ enormously in what they can accept. Cygenix assesses this before a run and says what it will and will not move, rather than failing partway through. Where a target cannot take an object, the equivalent construct is named.

Object	SQL Server	Azure SQL Managed Instance	Azure SQL Database	PostgreSQL
Server logins	Moves as-is	Moves as-is	Needs an equivalent Contained database users — CREATE USER … WITH PASSWORD, or FROM EXTERNAL PROVIDER for Entra.	Not possible CREATE ROLE … LOGIN, scripted by hand.
Server roles	Moves as-is	Moves as-is	Needs an equivalent Database roles, plus the built-in Azure SQL roles.	Not possible Group roles.
SQL Agent jobs	Moves as-is	Moves as-is	Needs an equivalent Elastic Jobs, or an Azure Automation runbook. Cygenix scripts the job for review; it does not translate it.	Not possible pg_cron, or an external scheduler.
SSIS projects	Moves as-is	Moves as-is	Needs an equivalent Azure-SSIS Integration Runtime, or Azure Data Factory.	Not possible None.
Linked servers	Moves as-is	Moves, with changes	Needs an equivalent External data sources — CREATE EXTERNAL DATA SOURCE, elastic query.	Not possible postgres_fdw.
Credentials and proxies	Moves as-is	Moves, with changes	Not possible	Not possible

Features

Feature	Status	From plan	Notes
AI column mapping	Available	Starter
Server-level object migration	Beta	Business	Logins with hashed passwords and SIDs, Agent jobs, SSIS projects and linked servers. Target support varies — see the server-object matrix.
Agentive migration	Beta	Pro
Validation and preflight	Available	Starter	Rule-based validation, preflight rejection forecasting, and per-job verify SQL.
Row-level reconciliation	Planned	Business	Row-hash diff across a source/target pair with a signed report. Not built. What exists today is validation and preflight — see above.
Tamper-evident audit trail	Available	Business	Hash-chained and append-only, with an admin screen, Recording/Paused/Off capture states, four categories that cannot be switched off, secret redaction before storage, a verification endpoint, AI actions recorded against the person they were taken for, and nightly retention that leaves a checkpoint so everything kept stays verifiable. Tamper-evident rather than tamper-proof: the blob store has no transactions, so a simultaneous append can race the head, and verification reports a break rather than hiding it.
Role-based access control	Available	Business	Ten roles, a permission matrix, separation of duties, and environment classification — all enforced server-side.
Restore database	Beta	Business
Data Stream	Preview	Business	Capture, Stream Store and delivery, running against seeded demo data. No connectivity to a real database or broker yet.
Cutover planning and delta re-sync	Planned	Business	Downtime estimation and a bounded incremental pass. Not built.
Shared team workspaces	Beta	Business	Projects belong to a workspace and colleagues join by invitation. Jobs, schedules and saved scripts are still personal — those live in Cosmos, partitioned per user, and moving them needs a container rebuild.
Change guardrails and the two-person rule	Beta	Business	Enforced server-side against a hash of the exact statement, so skipping the interface does not skip the guardrail. Covers writes to PROD and STAGING targets through the console.

Plan limits

Enforced server-side when a job is admitted. Exceeding one names the limit and the plan rather than failing generically.

Limit	Starter	Pro	Business	Enterprise
Concurrent migrations	1	3	10	Unlimited
Max rows per job	1,000,000	10,000,000	100,000,000	Unlimited
Job submissions a month	50	500	5,000	Unlimited
History retention (days)	30	90	365	365

Server migration

Schema and data are only half a migration. Logins, SQL Agent jobs, SSIS projects and linked servers live at the server level, and most tools either ignore them or make you script them by hand. Cygenix moves them in one auditable flow, from Dashboard → Run → Server Migration.

The flow has five stages, and you can stop after any of them:

Verify

Confirms both connections and checks you hold the rights the later stages need. Cygenix also reads the target’s engine edition here, because what a target can accept depends on it — see the server-object matrix.

Discover

Reads the source, read-only: logins from sys.server_principals and sys.sql_logins, Agent jobs from msdb, SSIS projects from the catalog, and linked servers with their provider options.

Assess

Every discovered object is checked against what the chosen target supports. Objects the target cannot hold are named, with the equivalent construct, before anything runs. Targeting Azure SQL Database, Cygenix will tell you that logins and Agent jobs cannot move and what to use instead — it will not start and drop them silently.

Preview

Generates one combined T-SQL script, in dependency order: categories, operators, credentials and proxies, schedules, then jobs and their steps. Logins script with PASSWORD = 0x… HASHED and SID = 0x… preserved, which is what keeps database users from being orphaned on the target. Review it before you run it.

Execute and audit

Applies against the target with per-object success or failure, and records what moved, what was skipped and why.

Never migrated: a remote or linked-server password. Linked-server login mappings are scripted with placeholders you supply. Cygenix does not read a password it cannot legitimately hold.

Connection strings

Direct SQL Server connection string

Standard ADO.NET format — works on-premises and Azure SQL:

Server=your-server.database.windows.net;Database=YourDB;User Id=user;Password=pass;Encrypt=true;TrustServerCertificate=false;

Azure Function (Managed Identity)

Recommended for Azure SQL — no passwords stored or transmitted:

https://your-function.azurewebsites.net/api/db?code=YOUR_FUNCTION_KEY

Tip: Save your connections in Project Settings → Connections. They are then pre-filled across the Mapper, Validation and SQL Editor.

Configure (live DB migration)

The legacy 5-step Configure wizard walks through source connection, target connection, column mapping, SQL preview and save. New migrations should use the Mapper directly, which provides a richer target-driven mapping experience.

Source database

Connect to the database you are migrating from. Use a direct connection string or Azure Function URL. Click Connect source DB to test and load the schema.

Target database

Connect to the database you are migrating into. Same connection modes as source.

Select & Map

Choose source and target tables. Claude AI maps columns automatically. Override any row using the dropdowns. Load Was/Is rules from the panel on the right.

Preview SQL

Fetch live rows from the source and review the generated INSERT statements before executing. Download as .sql if preferred.

Save & finish

Enter a job name and save. The job appears in All Jobs and the Conversion Project job library.

Mapper

The Mapper is the primary tool for building migration jobs. It offers two modes toggled at the top: Simple Map and One-to-Many.

Simple map

Maps one source table to one target table. The mapping grid is target-driven — every non-identity target column appears as a fixed row. You choose the source column from a dropdown.

AI map — Claude Haiku automatically maps all target columns. Retries automatically on overload (up to 3 attempts).
Fixed value — type any SQL literal in the Fixed value column to override the source. Examples: N'Enterprise', NULL, GETDATE(), 0
Truncation warning — if the source char type is wider than the target, a LEFT(N) badge appears and LEFT() is auto-applied in the SQL
Hide/Show Unmapped — toggle to show only columns that have a source or fixed value
Filter bar — filter rows by text or match level (HIGH / MEDIUM / LOW / Unmapped / Fixed)
Sort — click column headers to sort Source, Target or Match
Remove unused — removes unmapped rows from the generated SQL (with ↩ undo)

One-to-many map

Maps one source table into multiple target tables in a single operation. Add as many target table cards as needed using + Add target table.

Each card has its own target-driven mapping grid, AI map button, filter and Hide Unmapped toggle
PK mode per card: Identity (auto-increment), GUID (NEWID()), or Natural key
PK variable — name the variable (e.g. @ClientID) that captures the inserted PK for use in FK columns of child cards
FK rows — add foreign key columns that reference the PK variable of a parent card
Fixed value column per row — same as Simple map
Cards can be reordered with ↑ ↓ buttons

Generated SQL

SQL is generated automatically as you edit. Click Generate SQL to scroll to the SQL panel and refresh it explicitly.

Three-part database names: [SourceDB].[dbo].[table] and [TargetDB].[dbo].[table]
Bare column names in SELECT: [colName] (no schema prefix)
No GO statements — compatible with direct execution and batch runners
Was/Is rules appear as CASE WHEN blocks per column
Fixed values replace the source column directly in SELECT
LEFT(N) wrapping applied automatically for truncated char columns

Edit mode: Clicking Edit on any existing job opens the Mapper in edit mode. Both schemas are loaded, the mapping is restored (including fixed values and Was/Is rules) and SQL is regenerated silently.

SQL Editor

A full-featured SQL workspace for writing, running and managing scripts against source or target databases.

Script library — left panel. Save any number of named scripts. Click to load. Scripts persist in localStorage.
Connection selector — choose whether queries run against Source DB or Target DB
Keyboard shortcuts — Ctrl+Enter run, Ctrl+F find, Ctrl+/ toggle comment, Tab indent
Snippet toolbar — one-click SELECT, WHERE, INSERT, UPDATE, DELETE, BEGIN TRAN buttons
Results grid — row view or pivot view. Export to Excel. Rows capped in browser but all rows execute on server.
History — every executed query is stored with timestamp and result count. Click to reload.
AI assistant — describe what you need. Claude writes or improves the SQL. Click Apply to load into the editor.
Format SQL — uppercases all SQL keywords in the current script
Word wrap / Line numbers toggles
Fullscreen mode — hides the sidebar for maximum editor space
Load from file — open any .sql file directly into the editor

Job mode: SQL Editor also opens when you click Edit on a SQL-type job from the dashboard. The script is loaded automatically and a job indicator shows in the toolbar.

Was/Is mapping

Was/Is mapping translates specific values during migration — for example converting status codes A → Active, or renaming department codes to match the target system.

Prepare a CSV or Excel file with columns: field name, old value (Was), new value (Is). Load it in the Mapper using the Was/Is panel. Columns with rules applied show a N rules badge.

Note: Was/Is rules are case-sensitive by default. Ensure Was values exactly match the source data.

Data Validation

The Validation page runs SQL scripts to check data quality before and after migration. Unlike the old fixed-table approach, you can now add any table as a validation source.

Adding a validation table

Click + Add validation table. A modal walks through:

Connection

Pick Source DB, Target DB (from project connections), or type a custom connection string. Click Connect to load the schema.

Table picker

Search and select any table. The modal loads the row count and column list.

SQL column

Pick which column holds the SQL statement to execute. Each row in the table becomes one script. The SQL column is highlighted teal in the report column pills.

Script name column

Optional. Pick a column to use as the label for each script in the results table.

Report columns

All columns are shown as toggleable pills. Select which ones appear in the failure report when a script returns rows. All are selected by default — deselect what you don't need.

Run on

Choose whether the script SQL executes against Source DB, Target DB, or the same connection as the validation table itself.

Label

Give this validation source a friendly name (defaults to the table name). Click Save.

Running scripts

▶ Run all (topbar) — runs every script across all sources
▶ Run selected — runs only checked scripts
▶ Run (source card) — runs all scripts for that source only
▶ (row button) — runs a single script

A script ✓ Pass if it returns zero rows. It ✕ Fail if it returns any rows (those rows are the problem data). Click View on a failed script to see the rows inline, filtered to your chosen report columns.

Click Export to download an Excel file with a summary sheet and one sheet per failed script.

Tip: Validation sources are saved to localStorage (cygenix_validation_sources). Click Edit on any source card to update its column selections without losing the configuration.

Data Insights

Connect to any database table and load column data into the browser for quick analysis — distinct values, value frequencies, null counts, date ranges. Useful for understanding source data before mapping.

Performance settings

Access from Configure → Performance. Settings are saved to localStorage (cygenix_performance) and applied across all migration operations.

Quick presets

Preset	Best for	Key settings
Small DB	Tables under 100k rows	1,000 rows/page, 1 thread, row verification on
Medium DB	100k–1M rows	2,000 rows/page, 2 threads, balanced timeouts
Large DB	Over 1M rows	5,000 rows/page, 4 threads, NOLOCK, index hint
Azure SQL	Azure SQL databases	90s connect timeout, 5 retries, low concurrency
Cautious	Live production sources	100 rows/batch, 1 thread, full row verification

Key settings:

Fetch page size — rows fetched per round-trip from source. Reduce for wide tables with large text/blob columns.
Insert batch size — rows per INSERT VALUES (max 1,000 for SQL Server). Reduce for tables approaching the 8,060 byte row size limit.
Concurrent threads — parallel INSERT batches. Keep at 1–2 for Azure SQL Standard to avoid DTU spikes.
NOLOCK — enables READ UNCOMMITTED on source reads. Reduces lock contention on live databases but allows dirty reads.
Row verification — COUNT(*) check after each page insert to confirm rows were written.
Index disable hint — adds ALTER INDEX DISABLE/REBUILD comments in generated SQL (you run manually in SSMS).

Use Export to save settings as a JSON file. Use Import to restore from a saved file. The Configuration summary panel shows warnings for conflicting settings (e.g. API timeout less than query timeout).

Project settings

Access from Configure → Project Settings (or the dashboard sidebar). Fields include: project name, type, reference number, description, analyst, PM, client, start date, target completion date, migration phase, source system, target system, estimated rows and notes.

Important: The Target completion date drives the countdown in the summary stats bar.

Conversion Project

The Conversion Project Builder (Execute Jobs in the sidebar) sequences multiple migration jobs and custom SQL scripts into a single executable project.

Adding steps

Select migration jobs from the job library on the left
Add custom SQL steps — write any T-SQL to run on source or target
Add stored procedure call steps with parameters
Drag-and-drop to reorder steps

Running a project

Click ▶ Run project. Each step shows a live status: pending → running → complete / failed / error. On failure you can Retry, Skip or Abort the run. A full execution log is captured and included in the Conversion Report.

Conversion Reports

Export a client-ready Excel report from Reports → Conversion Report in the dashboard. The report includes:

Summary — project metadata, migration totals, row counts, error summary
Migration results — one row per job: source table, target table, rows migrated, rows verified, status
Column mapping — full mapping for each job including Was/Is rules applied
Execution log — timestamped log of every step
Was/Is rules — complete translation table used

Inventory

Store project documents, schema files, data dictionaries, mapping documents and Was/Is tables. Files can be uploaded, previewed (CSV, images) and downloaded. Client uploads appear in a separate Client submissions section.

Members, roles and guardrails

Everything about who reaches your work, and what they may do with it, lives on one page: Connect → Settings → Users & Roles. There is no step in any of it that happens in an identity provider's admin console.

Your workspace

Your projects belong to a workspace, not to you personally. Colleagues in the same workspace can open the same project; anyone outside it cannot see that the project exists — a request for one of its records answers not found, the same answer an address that has never existed would get. The attempt is recorded on our side at high severity.

Signing in does not put anybody in your workspace. A person who signs in without an invitation gets their own, empty, and sees nothing of yours. There is no domain matching: sharing an email domain admits nobody, because plenty of people share gmail.com.

Inviting somebody

Enter their address and choose their roles

On Members. The invitation names the roles the person will hold, so admitting them and deciding what they may do is one act rather than two that can drift apart.

They sign in with that address

That is the whole redemption. There is no link to click, no token to lose and no password for Cygenix to hold — they authenticate with Microsoft Entra as everyone else does. The invitation expires after fourteen days and can be revoked before it is used.

They appear under Users, already holding their roles

Change or revoke those roles at any time. A revocation takes effect on their next request, not their next sign-in.

Removing a member ends their membership and revokes every role they hold. It does not delete their work: their projects stay in the workspace, because a departing colleague's drafts are the customer's records.

What is shared and what is not

Object	Who sees it
Projects you create	Everyone in the workspace, by default. Set a project to private and only you can open it.
Projects that predate this	Private to whoever created them. Sharing a workspace does not publish work written before it existed — the owner shares it deliberately.
Deleting a shared project	The owner only. A colleague who can open it cannot destroy it.
Your Drive	You alone. The Drive is personal working documents, and a shared workspace does not imply shared files.
Jobs, schedules and saved scripts	Still personal, not yet shared within a workspace. This is the one part of the boundary that is not finished.

Change guardrails

A guardrail decides what must happen before a write runs against a classified target. It is set once for the workspace and enforced by the server: a request that skips the dialog gets the same answer the dialog would have insisted on.

Setting	What it means
Off	Nothing is gated. Writes run as soon as your roles allow them.
Confirm destructive only	A DELETE, TRUNCATE, DROP or an UPDATE with no WHERE clause must be confirmed. Ordinary writes run.
Confirm every change	Every write must be confirmed.
Two-person rule	Escalates the above: a gated change is queued and does not run until somebody other than the requester approves it. An Approver, Migration Lead or Platform Administrator can. Nobody approves their own request, and the sole approver of a change cannot be the one to execute it.

Guardrails apply to PROD and STAGING targets. An unclassified connection counts as PROD, so it is covered without anyone having to decide it should be.

A confirmation is issued by the server against the exact statement you are about to run. Editing the statement means confirming again; an approval cannot be spent twice, cannot be moved to a different target, and expires after fifteen minutes. Both the request and the approval land in the audit trail.

A workspace that existed before guardrails did starts with them off, so nothing changed underneath anyone. Turn them on from the same page.

Client Portal

Give clients a separate login that takes them to a simplified portal (/client.html) for uploading source data and notes.

Invite the client

Connect → Settings → Users & Roles → Members: enter their email address and give them the Member role. They join the first time they sign in with that address. Nothing happens outside Cygenix.

Assign their role

Roles are assigned inside Cygenix, in Connect → Settings → Users & Roles. There is no step outside the product and nothing to edit in an identity provider's admin console.

Ten roles are available, each with a fixed set of permissions enforced on the server: Organisation Owner, Platform Administrator, Migration Lead, Migration Engineer, Approver, Data Owner, Validator, Auditor, Member and Automation Principal. A user may hold more than one; where that collapses a separation of duties, Cygenix says so rather than hiding it.

Client logs in

Cygenix automatically routes them to the client portal, not the analyst dashboard.

Troubleshooting

Issue	Solution
Connection failed: Failed to fetch	Check the URL is correct. For Azure Function, ensure `?code=` key is included. Verify CORS is enabled for the Cygenix domain in the Azure Function App settings.
Non-JSON response (HTTP 500)	The Azure SQL database may be paused (auto-pause on free tier). Wait 20–30 seconds and retry. The first connection after a pause takes time to resume.
Login failed / token error	Managed Identity may not have database access. Run: `CREATE USER [identity-name] FROM EXTERNAL PROVIDER` and grant `db_datareader` / `db_datawriter`.
AI map error: Overloaded	Claude is busy. The mapper automatically retries 3 times with exponential backoff. If it still fails, wait a moment and try again.
AI map error: Unterminated JSON	The table has many columns and the AI response was truncated. The mapper applies automatic JSON repair. If columns are missing, try remapping individual sections.
Validation — table not found	Ensure the connection in the validation source matches the database where the validation table lives. Use Edit on the source card to update the connection.
Calendar events not showing	Task events appear only if the task has a start or due date set. Project completion appears only if a Target completion date is set in Project Settings.
Performance preset not applying	After clicking a preset, click Save settings. Presets fill the form but do not auto-save.
Jobs disappear after refresh	Jobs are stored in browser localStorage. Clearing browser data removes them. Export a backup from Configure → Backup & Restore before clearing storage.
Excel export does nothing	SheetJS is loaded on demand from cdnjs.cloudflare.com. Check internet connection. On corporate networks, whitelist `cdnjs.cloudflare.com`.

Need more help? Contact your Cygenix administrator or use the feedback button in the dashboard.

Cygenix AI Migration Platform · ← Back to Dashboard