# Migrating Off Altogic: The Rescue Playbook

- Tool: No-Code to Code Migrations
- Last updated: July 2026

## TL;DR

Altogic's status is genuinely uncertain: the npm SDK (@altogic/altogic) has not been published in approximately 3 years, and the Altogic team launched a separate open-source Kubernetes platform, Agnost — a classic 'team pivoted to successor' signal. No shutdown announcement has been confirmed as of July 2026, but data export mechanics are not clearly documented. Export everything you can today and begin migration planning immediately.

## Platform status

- Status: declining — Altogic marketing site and docs remain up (July 2026), but the npm SDK (@altogic/altogic) shows no publish in approximately 3 years (last active ~2022–2023). The Altogic team launched Agnost (agnost.dev), a separate open-source Kubernetes-native backend platform — a common 'pivot away from original SaaS' signal. No explicit shutdown notice found as of July 2026; status is genuinely at-risk. Sources: npmjs.com/~altogic; agnost.dev.
- Migration urgency: high
- Typical timeline: 6–10 weeks
- Typical cost: $13K–$25K (agency, fixed)

## Why migrate

Altogic shows the pattern of a platform whose team has moved to a successor product: stale SDK, no public roadmap updates, and a new open-source project from the same founders. The risk of waiting for an official announcement is that data may become inaccessible without warning.

- **npm SDK stale for approximately 3 years** — The @altogic/altogic npm package has not received a publish since approximately 2022–2023. A cloud BaaS platform whose client SDK receives no updates for this long is a critical signal — new features cannot be built on it and security vulnerabilities accumulate without patches.
- **Team pivoted to Agnost — the open-source successor** — The Altogic team launched Agnost (agnost.dev), an open-source Kubernetes-native backend platform. When the founding team builds and markets a successor product, the original SaaS is typically in quiet wind-down. This is the strongest signal that Altogic's future investment is going to Agnost, not Altogic Cloud.
- **Data export path not clearly documented** — Unlike Supabase, Appwrite, or PocketBase which provide clear migration/export guides, Altogic's data export mechanics are not clearly documented. There is no confirmed data portability guide or eject path. This means data recovery after a platform shutdown may not be possible through self-service.
- **Compliance posture unreliable for at-risk platform** — For a platform with uncertain operational status, SOC 2, HIPAA, and GDPR posture cannot be relied upon going forward. If you process regulated data on Altogic, the compliance risk of platform uncertainty is unacceptable.
- **Firebase alternative positioning overcrowded — no differentiation** — Supabase, Appwrite, and PocketBase have all substantially expanded since Altogic last updated competitively. The platform has not differentiated against these alternatives in years, making it harder to justify remaining on Altogic even if it continues operating.

## What you can export

Data export from Altogic is not clearly documented — do not assume a self-service eject path exists. Cloud Function source code is yours if you have local copies or can pull via CLI. Begin extraction immediately using every available API; don't wait for official guidance.

| Asset | Exportable | How |
| --- | --- | --- |
| Data | partial | Export mechanisms are NOT clearly documented; try every available Altogic REST API endpoint for data export; check Altogic docs for any backup/export features; contact support to request data export assistance |
| Code | partial | Altogic Cloud Functions were written in Node.js via Altogic CLI — use the CLI to pull all function source code to a local directory immediately; this is your code and is portable |
| Design/UI | no | n/a — Altogic is a headless BaaS; your frontend is separate code you own entirely |
| Logic/Workflows | partial | Cloud Functions (Node.js via Altogic CLI) are portable code — pull via CLI immediately; platform-level features (cron, queues, realtime) are infrastructure that must be rebuilt on the target platform |
| Users & Auth | partial | Auth user records export path NOT documented; try every available API to extract at minimum user email addresses; password hash export NOT documented |

## Stack mapping

The target stack is either Supabase (managed PostgreSQL + auth + storage + edge functions — the most mature managed option) or Agnost (the Altogic team's own open-source Kubernetes successor — architectural similarity may reduce rewrite scope); Altogic Cloud Functions port to Supabase Edge Functions or Next.js API Routes.

| Platform concept | Code equivalent |
| --- | --- |
| Altogic database (BaaS data store) | Supabase PostgreSQL or Agnost (OSS Kubernetes-native backend) |
| Altogic Cloud Functions (Node.js via CLI) | Supabase Edge Functions (Deno) or Next.js API Routes (Node.js) |
| Altogic Auth (email/password, OAuth, sessions) | Supabase Auth or Clerk |
| Altogic Storage (file storage) | Supabase Storage or S3/Cloudflare R2 |
| Altogic Realtime (WebSocket subscriptions) | Supabase Realtime channels |
| Altogic Cron jobs | Supabase pg_cron or Vercel Cron Jobs |
| Altogic Queues (task/message queues) | Supabase Edge Functions with Upstash Redis queue, or BullMQ on a small Node.js server |
| Altogic client SDK calls (@altogic/altogic) | @supabase/supabase-js client (functionally similar pattern) |

## Migration roadmap

Phase 0 — urgent data extraction — is non-standard and must come before any migration planning. You need to know what is recoverable before scoping the rest of the project. Do not begin Phase 1 until Phase 0 is complete.

### Phase 1: Phase 0: URGENT — data and code extraction (This week)

- Email Altogic support today asking: Is the platform actively maintained? What is the data export process? Is there a sunset timeline? Note the response time carefully.
- Use Altogic CLI to pull all Cloud Function source code to a local directory immediately
- Export all data via every available Altogic REST API endpoint; check docs for any backup or export features
- Export user list — at minimum: email addresses — via API so you can reach users in a password-reset campaign
- Download all files from Storage buckets; document bucket names and structure for re-upload to target

> Watch out: If Altogic support does not respond within 5 business days, treat non-response as a shutdown signal and accelerate migration immediately

### Phase 2: Phase 1: Audit and target selection (1 week)

- Inventory all data collections, auth users, storage buckets, cloud functions, cron jobs, and realtime channels
- Decide target: Supabase (mature, managed, most community support) or Agnost (same team's OSS successor, similar mental model)
- Document all Altogic SDK calls in frontend code — each one is a migration touchpoint
- Identify which Cloud Functions use Altogic-specific SDK internally vs standard Node.js logic

### Phase 3: Phase 2: Database and schema migration (1–2 weeks)

- Design PostgreSQL schema based on extracted Altogic data structure
- Import data into Supabase (or Agnost) using extracted API data; validate row counts and field completeness
- Apply Supabase RLS policies to secure data access per user role
- Verify data integrity with representative sample records before proceeding

### Phase 4: Phase 3: Function port and infrastructure rebuild (2–3 weeks)

- Strip Altogic SDK calls from Cloud Function code; rewrite as Supabase Edge Functions or Next.js API Routes
- Rebuild Altogic Cron jobs as Supabase pg_cron or Vercel Cron
- Replace Altogic Queues with Upstash Redis or BullMQ
- Replace Altogic Realtime subscriptions with Supabase Realtime channels in frontend code

### Phase 5: Phase 4: Auth migration and cutover (1 week)

- Configure Supabase Auth with OAuth providers; test all OAuth flows
- Execute password-reset campaign: send reset emails to all users; use magic links for first login
- Update all Altogic client SDK calls in frontend to Supabase SDK equivalents
- Cutover: point frontend to new backend; monitor error rates; decommission Altogic account

## Cost paths

| Path | Cost | Timeline | Fits |
| --- | --- | --- | --- |
| DIY with AI tools | $0–$500 + time | 2–4 months part-time | Developers who can write ETL scripts, have already pulled their function code via CLI, and have a small app with limited data collections and a handful of Cloud Functions |
| Freelancer | $3K–$8K | 4–8 weeks | Teams with moderate Altogic apps (a handful of collections, under 10 Cloud Functions, basic auth) where function code has already been extracted via CLI |
| Agency (RapidDev) | $13K–$25K fixed | 6–10 weeks | Teams with production Altogic apps and active users who cannot risk data loss or extended downtime; fixed price covers data extraction best-effort, function port, auth migration, and cutover with parallel-run validation |

## Risks and mitigations

- **Data may not be recoverable via self-service — no documented export path exists** — Start data extraction immediately using every available Altogic REST API; contact support for export assistance; do not wait for an official announcement — each day of inaction is a day of increased risk
- **User auth records at risk — no documented password hash export path** — Export user email list via any available API immediately; plan a full password-reset flow post-migration using magic links; communicate the transition to users before cutover
- **Cloud Function source code may exist only on Altogic servers if CLI sync was not used** — Use Altogic CLI to pull all function code to a local directory now, before access is lost; if CLI is non-functional, document all function logic from memory and recreate from scratch
- **Unknown shutdown timeline — no announcement means no export deadline warning** — Treat today as the deadline; the absence of an official shutdown notice does not mean the platform will remain accessible; the risk of waiting exceeds the cost of premature action
- **Agnost (OSS successor) may not be production-ready for all use cases** — Evaluate Agnost at agnost.dev against your specific workload; Supabase is more mature and managed; choose based on your team's operational capacity and the feature overlap with Altogic
- **Support non-response signals accelerated shutdown** — If Altogic support does not respond within 5 business days to a direct question about platform status and export options, treat it as a shutdown signal and immediately begin emergency migration

## Stay or go

Stay if:

- You receive a written response from Altogic support within 5 business days confirming: the platform is actively maintained, data export mechanisms are documented and working, and there is no sunset timeline — only stay with written confirmation in hand
- You have verified independently that the npm SDK is receiving updates and the engineering team is actively fixing bugs — not just infrastructure keeping the servers running
- You are actively evaluating Agnost (agnost.dev) as your migration target and are in the process of testing it — staying on Altogic temporarily while Agnost validation is underway is acceptable, provided you have already extracted all your data as a backup

Go if:

- The npm SDK (@altogic/altogic) has not been updated in years and you depend on it for any new feature development — a stale SDK means no new capabilities and accumulating security risk
- Altogic support is unresponsive or takes more than 5 business days to respond to a direct question about platform status — treat non-response as a shutdown signal
- Your app has active users whose data you are responsible for — the compliance and continuity risk of an uncertain-status platform is unacceptable for production workloads
- You cannot find clear documentation for exporting your data via self-service — a platform that doesn't document data portability cannot be trusted for business continuity

The evidence pattern — stale SDK, team pivot to a successor product, no public roadmap — is a clear signal that Altogic Cloud is in wind-down mode even without an official announcement. Do not wait for confirmation that may not come. Export everything you can today and migrate to Supabase or Agnost.

## Migration checklist

- Email Altogic support today asking three specific questions: Is the platform actively maintained? What is the data export process? Is there a sunset timeline? — Support response time and content is itself a signal — no response within 5 business days is a shutdown indicator; a detailed, current response lets you calibrate urgency accurately
- Use Altogic CLI to pull all Cloud Function source code to a local directory immediately — Your function code is your most portable asset; if CLI access is lost, source code may be unrecoverable — do this before anything else technical
- Export all data via every available Altogic API endpoint and document what is and is not recoverable — Altogic has no confirmed self-service export path; your data recovery depends entirely on what the current API exposes — you need to know this today
- Extract user email list via API — at minimum, every registered user's email address — Email addresses are the minimum needed to run a password-reset campaign post-migration; without them you cannot re-engage your users after cutover
- Download all files from Storage buckets and map the bucket structure — Altogic Storage files are binary assets not typically accessible via data API export; download them directly while access exists and document the folder structure for re-upload
- Document all Altogic SDK calls in your frontend and mobile code — Every Altogic SDK call is a migration touchpoint for the new client library; a complete list prevents missed replacements at cutover
- Evaluate Agnost (agnost.dev) alongside Supabase as migration targets — Agnost is built by the Altogic team with similar architectural concepts — the migration mental model may be shorter; compare both against your actual workload before committing to a target stack

## Frequently asked questions

### Is Altogic shutting down?

No official shutdown announcement has been made as of July 2026. However, the signals are concerning: the npm SDK (@altogic/altogic) has not been published in approximately 3 years, and the Altogic team launched Agnost (agnost.dev), an open-source successor product. This is a 'team pivoted to successor' pattern common in startup BaaS shutdowns. We recommend acting as if shutdown could occur without advance notice.

### Can I export my Altogic data?

Altogic's data export mechanisms are not clearly documented — unlike Supabase, Appwrite, or PocketBase, there is no confirmed self-service eject path. Try every available Altogic REST API endpoint for data export, check the docs for any backup features, and contact support directly to request export assistance. Do this today, not after you've decided to migrate.

### Can I export my Altogic Cloud Functions?

Yes — your Cloud Function code is written in Node.js via the Altogic CLI, and it is your code. Use the Altogic CLI to pull all function source code to a local directory immediately. If Altogic CLI sync was not used regularly, the source may exist only on Altogic servers — pull it now before access is potentially lost.

### How long does an Altogic migration take?

Typically 6–10 weeks with a team, assuming data recovery is successful. The unusually large variable here is Phase 0: data extraction. If Altogic's export APIs are limited, recovery time is unpredictable. Once you know what data is recoverable, the rest of the migration follows a standard BaaS pattern. Start the extraction before scoping the timeline.

### What happens to my users and their passwords when I migrate from Altogic?

Altogic's password hash export path is not documented. At minimum, export every user's email address via API so you can run a password-reset campaign post-migration. All users will need to reset their passwords — plan this as a first-class user communication, not an afterthought. OAuth users (Google, GitHub) re-authorize with the new provider and don't need password resets.

### Should I migrate to Supabase or Agnost?

Both are valid targets. Supabase is more mature, fully managed, has extensive documentation and community support, and offers a clear PostgreSQL-based mental model. Agnost (agnost.dev) is built by the Altogic team on Kubernetes — architectural similarity to Altogic may reduce migration scope, and if you're comfortable self-hosting Kubernetes, it could be a natural transition. Evaluate both against your team's operational capacity and specific feature needs before choosing.

### What if I can't recover my Altogic data through the API?

Contact Altogic support directly and request a data export or database dump. Document every interaction and response time. If support is unresponsive for more than 5 business days, escalate to any available contact channels (social media, community forums). Consider whether a legal data portability request is appropriate given your jurisdiction (GDPR Article 20 in the EU). Treat unresponsiveness as a signal to accelerate rather than wait.

### How much does an Altogic migration cost with an agency?

RapidDev offers fixed-price Altogic migrations at $13K–$25K, which covers data extraction best-effort, function port to Supabase Edge Functions, auth migration with password-reset campaign, storage migration, and cutover. The fixed price is scoped after Phase 0 (data extraction) confirms what is recoverable. Book a free scoping call at rapidevelopers.com to assess your specific situation.

---

Source: https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-altogic-project-to-code
© RapidDev — https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-altogic-project-to-code