Due to an NDA we can’t go into specific business details, but here’s the gist: we inherited a SaaS platform in the accounting and document processing space. The system handled document ingestion, automated data extraction, workflow orchestration, and multi-tenant reporting a fairly typical B2B back-office tool. The original stack was maintained by a team of two backend engineers and one frontend developer. What follows is a breakdown of what the migration to Elixir/Phoenix looked like by the numbers.

Migration Approach

Rather than attempting a gradual, service-by-service port, we took a clean-slate approach. We analyzed the existing MySQL schema to identify the core domain entities (files, accounting entries, companies, users, banks, VAT rates) and their relationships, then scaffolded a fresh Phoenix 1.8 project with phx.new and phx.gen.auth. DaisyUI and Tailwind v4 gave us a polished UI foundation out of the box. With the data model mapped and auth in place, we had a working MVP with file upload, document processing pipeline, and basic accounting views in under a week.

The following two weeks were spent reaching feature parity: porting the Zeebee BPMN workflows into Oban background jobs, reimplementing the React frontend screens as LiveView pages, and wiring up the same LLM and OCR integrations through Elixir’s Req HTTP client. Because Phoenix LiveView eliminated the entire REST API layer and frontend state management, features that previously required coordinating changes across three codebases (backend route, React component, Zeebee worker) could now be built end-to-end in a single Elixir module. The full migration from first commit to functional parity took approximately three weeks.

Let’s dive into raw numbers comparison

Migration Analysis: Numbers

Architecture Overview

1. Lines of Code Reduction

Net reduction: ~43,665 lines of code eliminated (from 68,850 to 25,185)

2. Source File Reduction

3. Dependency Reduction

4. Infrastructure Simplification

5. Language & Cognitive Complexity

6. Eliminated Entire Technology Layers

The migration completely removed these systems:

1. Camunda Zeebe - Workflow engine (Java-based, heavy) - replaced by Oban
2. Elasticsearch - Was only used as Zeebe exporter - eliminated entirely
3. Camunda Operate - Process monitoring UI - replaced by Oban Web dashboard
4. Redis - Caching layer - eliminated (BEAM VM handles in-memory state)
5. React + Redux - Entire SPA frontend (398 component files) - replaced by LiveView
6. npm/Node.js - Frontend build chain - replaced by esbuild + Tailwind (integrated)
7. gRPC - Zeebe inter-service communication - eliminated
8. REST API layer - 53 API route files - eliminated (LiveView is full-stack)
9. MySQL - replaced by PostgreSQL/SQLite3

7. Developer Experience Benefits

8. Operational Benefits

Summary Scorecard

The migration from a Python/React/Zeebee microservices architecture to a Phoenix monolith delivered a 63% reduction in code, 76% fewer files, and eliminated 9 entire technology layers while preserving the same document processing pipeline functionality.

There’s another dimension that doesn’t show up in line-of-code metrics: compliance. For any SaaS handling accounting data, certifications like ISO 27001, SOC 2, and GDPR audits are inevitable. Every service, dependency, and data flow in the architecture is a line item an auditor needs to review. Going from 6 Docker services to 2, from 218 dependencies across 3 ecosystems to 78 in one, and from 4 languages to 1 drastically shrinks the attack surface and the audit scope. Fewer moving parts means fewer CVEs to track, fewer access control boundaries to document, and a simpler data flow diagram to defend. What used to require mapping cross-service communication over gRPC and REST is now function calls within a single BEAM process. The compliance paperwork practically writes itself.

The original team of two backend engineers and one frontend developer has been replaced by a single Elixir developer maintaining the entire system.

• 1703 Group
• Me on X