SAP ASE (Sybase) DBA & Migration
Last reviewed by Tyler Eastridge
AceMQ provides remote DBA coverage and 24/7 support for SAP Adaptive Server Enterprise (SAP ASE, which many teams still call Sybase), and plans and runs the move to PostgreSQL when you decide to leave. AceMQ engineers lead each engagement and partner ASE specialists do the ASE-specific work, under one AceMQ contract. AceMQ is independent of SAP: it does not produce SAP patches, resell SAP licences or advise on them, and it does not rewrite your application code.
A senior engineer, not an SDR. No sales sequence attached.
Without a full-time ASE DBA or a big-bang rewriteFor production incident cover, see AceMQ SAP ASE (Sybase) 24/7 support.
Customers
Partners
The Problem
Eight SAP ASE problems that teams bring to AceMQ, from a dump nobody has restored to a log segment that filled and a move to PostgreSQL that has been quoted as mostly automatic. Each one maps to a service line below.
The one DBA who has restored an ASE dump to a new server is retiring, and nobody else has done it
A full log segment has suspended work at least once, and nobody wrote down why the transaction log was not truncated
A Replication Server or warm standby setup has run for years, and no one can say how far behind it is right now
A report that took minutes now takes hours, and statistics were last updated before the table grew
The maintenance dates for the release in use are unclear, and public summaries disagree
Hundreds of Transact-SQL stored procedures hold business rules and nobody knows how many would convert
A move to PostgreSQL has been proposed, with a vendor quote that calls most of it automatic
Applications rely on behaviour PostgreSQL does not share, such as procedures that return result sets straight to the client
A good fit if you run SAP ASE in production and need DBA cover that includes nights and holidays, or want a written view of what moving to PostgreSQL would involve before anyone commits. Not a fit if you want application code rewritten.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy SAP ASE (Sybase).
How it breaks, and the fix
When the primary fails, a standby has to be promoted. If standby A has not received the latest transactions, promoting it loses what it never got, while standby B is current. Which one you promote, and how connections reach it, decide how much is lost and how long the outage runs.
Primary lost, one standby behind
One ASE primary and two standby copies, reached through a connection layer
The primary serves the application and both standbys receive its changes. Replication latency stays low and someone watches it.
The primary fails. Standby A has fallen behind on replicated transactions and standby B holds nearly everything. Promoting the wrong one would lose committed work.
Standby B is promoted and connections move to it. Standby A is rebuilt or resynchronized behind the new primary, and the old primary is investigated before it rejoins.
The failover is the easy part. What decides the outcome is set months earlier: whether replication is asynchronous, as it is with Replication Server, so a lag means lost transactions; how the lag is measured and who is paged for it; whether transaction log dumps run often enough that the log segment never fills; whether the standby has been loaded from a dump and checked recently; and whether applications reconnect on their own or need a restart. The same questions return in a migration, where a change feed to a PostgreSQL target plays the part of the standby.
Our Services
AceMQ runs five SAP ASE service lines: remote DBA service, performance and capacity review, backup, recovery and replication review, a fixed-scope health check, and migration to PostgreSQL. Any of the first four can roll into 24/7 on-call with a 15-minute emergency SLA.
Day-to-day SAP ASE database administration done remotely by AceMQ and a partner ASE DBA, covering for a retiring DBA or a gap in the team.
A recurring look at the statements that cost the most, the plans that changed and the headroom left, using ASE's own monitoring.
Recovery you have proven, and a view of replication that someone watches.
The fixed-scope entry engagement: a written report on the state of the estate that your own team can act on, with or without AceMQ afterwards.
Assessment, conversion planning, data movement, validation and a rehearsed cutover, with ASE supported until the last database moves.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ SAP ASE support gives you an AceMQ engineer and a 15-minute first response when a server is down or failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Patches still come from SAP: AceMQ does not produce them.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ SAP ASE engagement runs in four stages: a scoping call with a quote within 1 hour, a read-only inventory, a written options paper that compares staying, moving and doing both, then ongoing cover or migration rehearsals. Each stage ends in writing.
Quote within 1 hour
The first call settles one question: keep ASE healthy, leave it, or both. An AceMQ engineer takes the ASE release and EBF level, number of servers and databases, Replication Server or warm standby, backup method and who is on call today. A quote request is answered within 1 hour.
Scoped per estate
A read-only inventory of servers, databases, devices, stored procedures, triggers, replication definitions, scheduled jobs, and the clients and drivers that connect. It also records the dump schedule, the last restore test and what the monitoring tables say is still being called.
Scoped per estate
A written comparison of staying on ASE with DBA cover, a phased move to PostgreSQL, and both at once. It names the SAP maintenance position you must confirm from SAP's own notes, the objects that need hand work, and the order we would move databases in.
Ongoing or per project
Remote DBA work and on-call response with a 15-minute P1 SLA while ASE runs, and migration rehearsals and a rehearsed cutover when you move. A written review follows each incident and each rehearsal.
A senior engineer, not an SDR. No sales sequence attached.
Move to PostgreSQL
Tools move ASE tables and a good share of the code. The effort sits in the Transact-SQL stored procedures and the applications that call them, so the inventory comes first and the cutover is rehearsed before it is scheduled.
Inventory
Servers, databases, tables, stored procedures, triggers, rules and defaults, user-defined types, replication definitions, jobs, and the clients that connect. ASE's monitoring tables, read over a representative period, show which procedures are called, so dead code is not converted.
Convert
AWS Schema Conversion Tool lists SAP ASE as a source and Amazon RDS for PostgreSQL and Aurora PostgreSQL as targets, and flags what it cannot convert. ASE and Microsoft SQL Server share Transact-SQL roots, but Babelfish publishes SQL Server's dialect, not ASE's, as its compatibility target. The hand work is usually the same few things: procedures that return result sets to the client, transaction control inside procedure bodies, trigger logic that uses the inserted and deleted tables, legacy outer-join operators, temporary tables scoped to a procedure, a case-insensitive sort order, and timestamp columns that are row versions rather than dates.
Move data
A full load fits a window. For ongoing change capture, AWS DMS reads ASE's log, but its documentation lists limits that can decide the plan: one change-capture task per database, no clusters or warm standby as a source, no user-defined type columns, and no table or column renames while it runs. Any reader that holds a truncation point also stops ASE truncating its log if it stalls, so we watch it.
Prove and cut over
Row counts and checksums on key tables, the same reports run on both engines, a procedure test pass, and performance on realistic data. The cutover plan freezes writes, finishes the sync, repoints connections and keeps ASE read-only for an agreed window as the way back.
Typical engagements
Typical SAP ASE engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Distribution Business
A typical engagement: inventory the SAP ASE servers, databases and Transact-SQL code behind an order system, map them to PostgreSQL, and plan rehearsals before anyone commits to a date.
PostgreSQLAWS Schema Conversion Tool
Telecommunications Operator
Remediation of a Grafana deployment that became unusable during incidents, with dashboards timing out exactly when engineers needed them most.
Grafana
Prometheus
KubernetesPostgreSQL
Digital Media Platform
Ongoing support for a Memcached tier prone to thundering-herd database load after node changes and cache expiry cliffs.
Memcached
LinuxPostgreSQLKubernetesSolutions
AceMQ covers SAP ASE (Sybase) end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed SAP ASE (Sybase) on your infrastructure and fully managed SAP ASE (Sybase) on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running SAP ASE (Sybase) for you.
Compare the four SAP ASE (Sybase) support tiersSide by side
SAP's maintenance supplies ASE fixes while a release is in maintenance; it does not run your servers. AceMQ supplies the engineers who do, alongside SAP or after you leave ASE. Each row below answers one question about the choice.
| Question | SAP maintenance alone | SAP maintenance plus AceMQ | Move to PostgreSQL with AceMQ |
|---|---|---|---|
| Where do fixes come from? | SAP, while your release is in maintenance. Confirm the date in SAP's own note for your release. | SAP, as before. AceMQ's engineers plan and apply them. AceMQ produces no SAP patches. | The PostgreSQL project's release process after cutover. Until then, ASE keeps its SAP position. |
| Who answers at 3am? | SAP support through your contract, and your own DBAs. | An AceMQ engineer within 15 minutes, 24/7, with your SAP support contract behind them for bugs that need an SAP fix. | An AceMQ engineer on ASE until the last database moves, then on PostgreSQL. |
| What changes in the application? | Nothing. | Nothing. | Drivers, SQL dialect and any procedure that depends on ASE behaviour. The inventory sizes this before anyone commits. |
| What is the main risk? | The release leaves maintenance, and the number of people who know ASE shrinks. | The same release risk, with the people risk covered. | Conversion effort hidden in stored procedures and triggers, and a cutover that has not been rehearsed. |
| When does it fit? | You have ASE DBAs in-house and a release that SAP still maintains. | You want ASE to stay stable and covered while you decide, or while a move is built. | You have decided to leave ASE, or want the facts for that decision first. |
AceMQ gives no SAP licensing advice. Read your SAP agreement and SAP's maintenance note for your release before you choose.
One partner, not five
SAP ASE (Sybase) rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on moving to PostgreSQL, plus the AceMQ services around it: PostgreSQL support, database consulting and managed open-source operations.
FAQs
Five answers on SAP ASE from AceMQ: patches and SAP support, maintenance dates, what converts to PostgreSQL, which Sybase products are covered, and keeping ASE healthy during a move.
Still have questions about SAP ASE (Sybase)? Email an Expert
No. Patches and fixes for ASE come from SAP under your SAP agreement, and AceMQ produces none. AceMQ is independent of SAP and gives no SAP licensing advice. What it supplies are the engineers who administer, troubleshoot and tune ASE and plan the move off it, alongside SAP support or after you stop using it.
SAP publishes end-of-maintenance dates for each ASE release in an SAP note that needs an SAP login. Public summaries of ASE 16.0's end of mainstream maintenance disagree, 31 December 2025 in one and 31 December 2027 in another, so this page prints no date. Read SAP's note for your release and send it with your quote request; the plan starts from that date.
Schemas and a share of the stored procedure code. AWS Schema Conversion Tool lists SAP ASE as a source and Amazon RDS for PostgreSQL and Aurora PostgreSQL as targets, and marks what it cannot convert. Treat the output as a first draft for an engineer to review. The effort is in procedures, triggers and the applications that depend on ASE behaviour.
SAP ASE is the scope. Replication Server is read as part of an ASE estate because it moves ASE data. SAP IQ and SQL Anywhere are scoped case by case, and AceMQ may decline them.
Yes, and that is the usual order. A health check and remote DBA cover keep ASE stable while the inventory, rehearsals and cutover plan are built. Support continues until the last database has moved.
Yes. AceMQ works on SAP ASE (Sybase) in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your SAP ASE (Sybase) environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how SAP ASE (Sybase) is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your SAP ASE estate, tells you what cover or migration plan fits, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email a SAP ASE (Sybase) Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
