Sybase to Postgres®, without a rewrite from scratch.
EDB Migration Toolkit officially supports SAP® Adaptive Server Enterprise 15.7 and 16.0 as a source database, migrating schemas and data into EDB Postgres® AI (EDB PG AI). Mainstream maintenance for ASE 16.0 ends December 31, 2027.
Why teams are planning the move now
The date is fixed, and the work is long
SAP Note 1922006 sets ASE 16.0 end of mainstream maintenance at December 31, 2027. A phased migration of a large estate runs 20–44 weeks. The two numbers only fit together if planning starts well before the deadline does.
An audit question you'll be asked
PCI DSS v4.0.1 Req. 12.3.4 requires an annual review of whether each technology still receives vendor security fixes, plus a documented, management-approved remediation plan for any technology whose vendor has announced end-of-life dates. That review reaches ASE on its own schedule, not yours.
Specialist expertise is a planning constraint
ASE-specific skills are specialized and concentrated. That matters less for keeping the lights on than it does for staffing a migration—it's a resourcing question to answer early, not a reason to rush.
What actually converts, and what needs a closer look
EDB Migration Toolkit lists SAP ASE 15.7 and 16.0 as officially supported source databases, migrating into EDB PG AI. For ASE sources the toolkit migrates schemas, tables, constraints, indexes, and table data. Views, stored procedures, triggers, and functions are not migrated by the toolkit; they are rewritten in PL/pgSQL as part of the project.
Sybase ASE construct | EDB PG AI equivalent | What to expect |
|---|---|---|
Tables, indexes, constraints | Direct schema objects | The deterministic part. Migrated by Migration Toolkit with minimal intervention; check constraints and default clauses need the -ignoreCheckConstFilter option. Views are not migrated for ASE sources: recreate them once the base tables land. |
IDENTITY columns | Identity columns or sequences | Confirm in the schema assessment how each IDENTITY column is carried over, then verify seed and increment behavior after cutover. |
T-SQL stored procedures & triggers | PL/pgSQL, rewritten | The bulk of the effort on any ASE estate. The toolkit does not migrate procedures, triggers, or functions from ASE, so this is a rewrite, and procedural density is the single biggest driver of timeline. |
Temporary tables | TEMP tables with Postgres scoping | Semantics differ. Scope and lifetime need review where procedures rely on ASE's behavior. |
Lock-based concurrency | MVCC | Not a translation—a behavioral change. Code written around ASE's deterministic locking needs isolation-level review, and this is where latency-sensitive systems need real testing. |
Application drivers & transaction semantics | PostgreSQL drivers | Application-layer work, outside the database migration itself. Scope it separately. |
Construct mappings reflect EDB Migration Toolkit's documented object support for ASE sources. Effort per object varies with procedural complexity—confirm against a schema assessment of your own estate.
On the tooling landscape, plainly: there is no community-standard Sybase converter the way ora2pg serves Oracle® or pgloader serves MySQL®. Sybase migration is commercial-tool territory, and most of that territory consists of converters sold by vendors who don't also support the database you land on.
That's the practical difference here. Migration Toolkit, EDB PG AI, and the support contract for the resulting system come from one vendor, which matters most in the first weeks after cutover when something behaves differently than it did on ASE.
How long a Sybase migration takes
Every migration runs two clocks: how long the project takes, and how long the system is offline at cutover. Downtime tolerance drives the strategy; the strategy drives the timeline.
Source | Offline backup & restore | Near-zero downtime CDC / logical replication | Phased / shadow parallel run, then cutover |
|---|---|---|---|
Sybase / SAP ASE | 3–6 wks 6–16 hr downtime | 8–18 wks <30 min downtime | 20–44 wks 0 min downtime |
SQL Server | 2–4 wks 4–12 hr downtime | 6–16 wks <30 min downtime | 16–34 wks 0 min downtime |
DB2 | 3–6 wks 6–16 hr downtime | 8–20 wks <30–45 min downtime | 26–52 wks 0 min downtime |
MySQL | 1–2 wks 2–8 hr downtime | 4–12 wks <15 min downtime | 12–26 wks 0 min downtime |
Planning ranges, not commitments. Sybase sits at the slower end because the ASE dialect and scarce specialist expertise stretch both assessment and testing. Ranges vary with stored-procedure complexity, custom code, and data volume — confirm with a migration assessment. Source: EDB migration engineering estimates, compiled from completed customer engagements, 2026 (internal; actual ranges vary by estate and are confirmed during assessment).
How a migration runs, end to end
The same five stages, in the same order, on every source database EDB migrates. Assessment first, validation last, nothing skipped.
Assess
Schema and complexity analysis across the estate
Transform
Schema and procedural code conversion
Remediate
Resolve the edge cases conversion leaves behind
Move
Coordinated data transfer and sync
Validate
Integrity, correctness and performance checks
Where agent-assisted execution fits. EDB's agentic migration capability—the closed-loop pipeline that automates these five stages—is an emerging capability, currently scoped to Oracle® and cloud-locked Postgres sources. For Sybase, the same five stages are executed with EDB Migration Toolkit, EDB PG AI, and EDB migration architects.
The methodology is the same. The degree of automation is not—so scope Sybase engagements on the tooling-assisted path rather than the agent-assisted one.
What's on the other side of the migration
Where the migrated system runs
Self-managed
Run EDB PG AI on your own infrastructure, on-premises, or in your own cloud accounts.
Hybrid Manager
One control plane across on-premises and cloud estates, for organizations that aren't consolidating onto a single environment.
Managed platform
A managed service where EDB operates the platform and your team keeps the workload.
Deployment choice is independent of migration strategy—the timeline table above applies to all three.
Take it to your team
Compliance
Brief
Migration
Playbook
Documentation
Start with an assessment, not a commitment
Bring your ASE environment to a migration architect—schema complexity, downtime tolerance, and what converts automatically versus what needs a closer look. The output is a scoped timeline you can take to a budget conversation.