Coder Legion - Recent posts tagged legacy

Rewrite or Refactor a Legacy Application? How to Decide

Fri, 16 Oct 2026 14:55:27 +0000

Every business with an ageing application eventually faces the same question: do we rewrite or refactor the legacy application? Get it wrong and you either burn a year rebuilding something that already worked, or you pour money into patching a system that cannot be saved.

I handle this decision as part of legacy application modernization work, and the honest answer is almost never "rewrite everything" or "leave it alone". This guide gives you a practical way to decide, the questions I ask, and the middle path that usually wins.

What "legacy" actually means

Old code is not automatically legacy code. An application is legacy when it is hard to change safely. Typical signs:

Nobody dares to deploy on a Friday, or at all
Only one person understands how it works
The framework or language version no longer gets security updates
Simple changes take weeks because everything is tangled together
There are no tests, so every change is a gamble
Hosting and dependencies are frozen because upgrading might break things

If the app is old but stable, tested and easy to change, it is not your problem. If it is new but a mess, it might be.

The three options, in plain terms

Refactor in place. Improve the existing code step by step without changing what the system does: add tests, clean up the worst areas, upgrade dependencies.
Rewrite from scratch. Build a new system and switch over when it is ready.
Modernise incrementally. Replace the system piece by piece while the old one keeps running. This is often called the strangler pattern, described well in Martin Fowler's write-up of the Strangler Fig approach.

Most teams think they have two choices. The third is what usually works.

Why big-bang rewrites fail so often

A full rewrite looks attractive: clean code, modern tools, no baggage. The problem is that the old system contains years of quiet business knowledge: edge cases, workarounds, rules nobody wrote down. Joel Spolsky made this argument in his classic essay Things You Should Never Do, Part I, and it still holds up.

In practice, rewrites go wrong for predictable reasons:

The old system keeps changing while you build the new one, so you are chasing a moving target.
You ship nothing for months, so the business pays but sees no value.
Hidden behaviour is lost because nobody remembers why it worked that way.
Scope grows, because a rewrite invites "while we're at it" features.

That does not mean never rewrite. It means be sure you must, and limit the blast radius.

A decision framework you can use this week

Score your system on these questions. I use them in audits.

1. Can the system still do its job? If it works and the business is not blocked, you have time to move carefully. If it is failing daily, you may need to stabilise first.

2. Is the technology end-of-life? An unsupported framework or language version is a security and hiring risk. That pushes you toward upgrading or replacing, not ignoring.

3. Is the data model sound? A good database under a messy application is a great position. A broken data model is a much bigger problem than ugly code.

4. Can you test it? If you can add tests around key flows, refactoring becomes safe. If the code cannot be tested at all, that is a strong signal to replace parts of it.

5. How tangled are the pieces? Systems with clear boundaries can be replaced one module at a time. A single ball of mud is harder.

6. What does the business need next? If the next year's roadmap is mostly new features, spend effort where those features land, not on parts nobody touches.

7. Who knows the system? If that knowledge is walking out the door, document and test first, whatever you choose.

When refactoring is the right call

Choose refactoring when:

The framework is still supported or has a clear upgrade path
The data model is sound
The pain is concentrated in a few areas
You can put tests around the critical flows

I often start with exactly this: map the dependencies, add tests around the riskiest workflows, fix the worst hotspots, and upgrade in steps. My Laravel upgrade checklist walks through that approach for older Laravel apps.

When a rewrite is justified

A rewrite makes sense when:

The platform is end-of-life with no sensible upgrade path
The architecture fundamentally cannot support what the business needs
The system is small enough to rebuild in a short, fixed window
The code is so untestable that incremental change is not possible

Even then, I prefer to rebuild in slices, with the old system running beside the new one.

The incremental path most businesses should take

The approach I recommend most often has five steps:

Audit first. Understand the workflows, the database, the dependencies and the risks before deciding anything.
Stabilise. Fix security gaps, add monitoring and backups, and make deployments repeatable.
Add tests around the flows that matter most.
Replace one slice at a time. Pick a self-contained module, rebuild it in the new stack and route traffic to it.
Retire the old parts once the new ones have proven themselves.

Each step delivers something the business can see, and each one can be paused or reversed.

What drives the cost either way

I will not quote a number without seeing the system, but these factors move cost and timeline the most:

Size and complexity of the application, especially the number of distinct workflows
Test coverage, because untested code costs more to change safely
Data migration, since moving and validating years of records is often the riskiest step
Integrations with payment, shipping, CRM and other third-party services
How much downtime the business can tolerate during the switch
Documentation and access, because missing knowledge slows everything down

An audit before the main work is usually the cheapest way to turn these unknowns into a plan you can budget.

A real-world example

On the PPCWA freight-forwarding audit, I was brought in to audit and stabilise a nearly completed Core PHP and MySQL platform. The work focused on understanding the existing system first: workflows, database structure, frontend maintainability, dependencies and configuration. I also assessed the architectural path toward a future Laravel migration. The point was to decide with evidence instead of opinion. I describe a related migration in migrating a legacy Core PHP platform to Laravel and a Laravel-specific version in Laravel 5 migration strategy.

Questions to ask any developer or agency

If someone recommends a rewrite, ask:

What did you find in the existing system that cannot be improved?
How will we keep the business running during the work?
Which parts will go live first, and when?
How will you protect the data and the undocumented business rules?
What is the plan if the project overruns?

A good partner answers with specifics. A weak one answers with enthusiasm for new technology.

Key takeaways

"Legacy" means hard to change safely, not just old.
Big-bang rewrites fail because they lose hidden business knowledge and deliver late.
Audit first, then choose refactor, rewrite or incremental replacement with evidence.
Incremental modernisation is usually the lowest-risk option.
A sound data model and testable flows tilt the decision toward refactoring.

If you are weighing this decision for your own application, book a call and I will tell you which path I would take and why.

Originally published at aqibjavaid.site.

Modernizing Legacy Software

Wed, 26 Aug 2026 09:00:00 +0000

In this episode of Continuous Delivery Office Hours, Tony Kelly chats to Bob Walker and Steve Fenton about modernizing legacy applications.

Many teams and organizations face the decision on whether to modernize software that's been running for years, and it's no small undertaking.

Listen to find out more about:

Why legacy applications are still hanging around
The common approach (that's certain to fail)
What approaches work when you need to update or replace a legacy application

Migrating a Legacy Codebase Across 15+ Modules Without Downtime: An Engineering Transformation Story

Thu, 09 Apr 2026 10:50:00 +0000

Legacy code is not a dirty word — it is code that makes money, serves real users, and pays engineering salaries. The problem is not its existence, but that it eventually accumulates enough technical debt to slow the entire business down.

I know this because I have spent the past three years living it. Since September 2022, I have been working as a Full Stack Engineer at VacancySoft, a data intelligence company whose platform serves vacancy data to clients across the recruitment and professional services industries. When I joined, the platform ran on a legacy monolith that had served the company well — but was buckling under 50,000+ daily API requests, growing data volumes, and a feature velocity the architecture could no longer support.

Over the following months, I led the architectural redesign and incremental migration of 15+ modules to a modern Node.js/TypeScript architecture — without a single minute of planned downtime. This is the story of how we did it: the strategy, the patterns, the code, and the results.

The Problem: A Monolith Under Pressure

The platform had the hallmarks of a system that grew organically over many years — not badly built, but built for a different era. By the time I joined, several compounding issues were creating real business impact:

Technical Debt Symptoms

Inconsistent module architecture. Each of the 15+ modules had been built by different engineers at different times. Some used callbacks, others early Promises, a few had partial async/await. There was no unified error handling, no consistent validation layer, and no shared utility patterns.

Tightly coupled database queries. Business logic was interleaved with raw SQL scattered throughout controllers and route handlers. Schema changes required tracing query strings across dozens of files, with no ORM or query builder providing a single source of truth.

No TypeScript, no type safety. The entire codebase was plain JavaScript. Refactoring any function required manually tracing every call site to understand expected input and output shapes. Function signatures were documented only in the minds of the original authors — several of whom had left the company.

Test coverage below 15%. Critical business logic — data transformation, API response formatting, access control — had no automated tests. Every deployment was a manual QA exercise, and regressions were discovered by clients.

Business Impact

These issues translated directly into business problems:

Feature delivery had slowed ~40%. Engineers spent more time working around existing code than writing new functionality.
Query execution times had degraded. Key client-facing endpoints were responding in 2+ seconds, triggering SLA concerns.
Deployment confidence was low. Without test coverage, the team batched changes into infrequent releases rather than shipping continuously.
Onboarding new engineers took weeks. Missing type definitions, documentation, and consistent patterns meant new team members needed extensive hand-holding.

The codebase needed a fundamental transformation — but the platform was in active use by paying clients. A "big bang" rewrite was commercially unacceptable. We needed to modernise incrementally while keeping the platform fully operational.

My Role: Architect and Migration Lead

I drove the migration strategy from conception to execution — designing the architectural approach, selecting the migration pattern, defining TypeScript adoption standards, establishing the testing strategy, and personally leading the refactoring of the most complex modules. I also mentored other engineers through the transition, running code reviews to ensure consistency.

This was not a committee decision. I proposed the strangler fig approach to leadership, built the proof of concept on the first module, and established every pattern the rest of the migration followed.

The Strategy: Strangler Fig Pattern

I chose the strangler fig pattern — named after the tropical vine that gradually envelops and replaces its host tree. Rather than rewriting everything at once, we would build new implementations alongside legacy code, gradually routing traffic to new modules, and removing old code once each was fully replaced.

This approach offered three critical advantages:

Zero downtime. At no point would the platform be partially functional. Both old and new implementations ran simultaneously.
Incremental risk. Each module migration was an isolated, reversible change. If a new module had issues, we could route traffic back to the legacy implementation within seconds.
Continuous feature delivery. The team could ship new features on modules that had not yet been migrated, while migration work progressed in parallel on other modules.

The Migration Architecture

I designed a proxy layer sitting in front of both legacy and new implementations:

// migration-router.ts — Proxy layer for gradual migration
import { Request, Response, NextFunction } from 'express';
import { FeatureFlagService } from './services/feature-flags';

interface MigrationRoute {
  legacyHandler: (req: Request, res: Response, next: NextFunction) => void;
  modernHandler: (req: Request, res: Response, next: NextFunction) => void;
  moduleName: string;
}

export function createMigrationRouter(route: MigrationRoute) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const useModern = await FeatureFlagService.isEnabled(
      `migration:${route.moduleName}`,
      { userId: req.user?.id }
    );

    if (useModern) {
      return route.modernHandler(req, res, next);
    }

    return route.legacyHandler(req, res, next);
  };
}

Feature flags controlled which implementation served each request. I could migrate internal users first, then roll out to 10%, 25%, 50%, and finally 100% of client traffic — monitoring error rates and response times at every stage.

Technical Deep Dive: The Migration Process

Phase 1: TypeScript Foundation and Shared Infrastructure

Before migrating any module, I established the shared infrastructure every new module would depend on.

TypeScript Configuration

I introduced TypeScript with a strict configuration enforcing type safety from the start:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "esModuleInterop": true,
    "sourceMap": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "paths": {
      "@modules/*": ["src/modules/*"],
      "@shared/*": ["src/shared/*"]
    }
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist", "legacy/**/*"]
}

The strict: true flag was non-negotiable. I had seen migrations where strict: false was used to avoid friction, yielding TypeScript no safer than the JavaScript it replaced.

Shared Data Access Layer

I built a unified data access layer replacing scattered raw SQL queries with typed repository patterns:

// shared/repositories/base.repository.ts
import { Pool, QueryResult } from 'pg';
import { DatabasePool } from '../database/pool';

export abstract class BaseRepository<T> {
  protected pool: Pool;

  constructor() {
    this.pool = DatabasePool.getInstance();
  }

  protected async query<R = T>(
    sql: string,
    params: unknown[] = []
  ): Promise<R[]> {
    const start = Date.now();
    const result: QueryResult = await this.pool.query(sql, params);
    const duration = Date.now() - start;

    if (duration > 500) {
      logger.warn('Slow query detected', {
        sql: sql.substring(0, 200),
        duration,
        rowCount: result.rowCount,
      });
    }

    return result.rows as R[];
  }

  protected async queryOne<R = T>(
    sql: string,
    params: unknown[] = []
  ): Promise<R | null> {
    const rows = await this.query<R>(sql, params);
    return rows[0] || null;
  }

}

Every migrated module used this base repository, giving us automatic slow query logging, consistent error handling, and typed return values. The legacy code had none of this — slow queries went undetected until clients complained.

Standardised Error Handling

I introduced a typed error hierarchy replacing the inconsistent error handling across the legacy codebase:

// shared/errors/application-errors.ts
export class ApplicationError extends Error {
  constructor(
    message: string,
    public readonly statusCode: number,
    public readonly code: string,
    public readonly isOperational: boolean = true
  ) {
    super(message);
    this.name = this.constructor.name;
    Error.captureStackTrace(this, this.constructor);
  }
}

export class NotFoundError extends ApplicationError {
  constructor(resource: string, identifier: string | number) {
    super(
      `${resource} with identifier '${identifier}' not found`,
      404,
      'RESOURCE_NOT_FOUND'
    );
  }
}

export class ValidationError extends ApplicationError {
  constructor(
    public readonly errors: Array<{ field: string; message: string }>
  ) {
    super('Validation failed', 400, 'VALIDATION_ERROR');
  }
}

Phase 2: Module-by-Module Migration

With the foundation in place, I began migrating modules from lowest-risk to highest-risk — starting with lower-traffic, simpler modules to build confidence before tackling the complex, high-traffic ones.

Before (Legacy JavaScript):

// legacy/controllers/vacancyController.js
const db = require('../db');

exports.getVacancies = function(req, res) {
  var page = req.query.page || 1;
  var limit = req.query.limit || 50;
  var offset = (page - 1) * limit;
  var sector = req.query.sector;

  var sql = 'SELECT * FROM vacancies';
  var params = [];

  if (sector) {
    sql += ' WHERE sector = $1';
    params.push(sector);
  }

  sql += ' ORDER BY created_at DESC LIMIT $' + (params.length + 1) +
         ' OFFSET $' + (params.length + 2);
  params.push(limit, offset);

  db.query(sql, params, function(err, result) {
    if (err) {
      console.log('Error fetching vacancies:', err);
      return res.status(500).json({ error: 'Internal server error' });
    }

    db.query('SELECT COUNT(*) FROM vacancies' +
      (sector ? ' WHERE sector = $1' : ''), sector ? [sector] : [],
      function(err2, countResult) {
        if (err2) {
          return res.status(500).json({ error: 'Internal server error' });
        }
        res.json({
          data: result.rows,
          total: parseInt(countResult.rows[0].count),
          page: parseInt(page),
          limit: parseInt(limit)
        });
      }
    );
  });
};

After (Modern TypeScript):

// modules/vacancies/vacancy.controller.ts
import { Request, Response } from 'express';
import { VacancyService } from './vacancy.service';
import { GetVacanciesSchema } from './vacancy.validation';
import { asyncHandler } from '@shared/middleware/async-handler';

export class VacancyController {
  constructor(private readonly vacancyService: VacancyService) {}

  getVacancies = asyncHandler(async (req: Request, res: Response) => {
    const query = GetVacanciesSchema.parse(req.query);

    const result = await this.vacancyService.getVacancies({
      page: query.page,
      limit: query.limit,
      sector: query.sector,
      sortBy: query.sortBy,
      sortOrder: query.sortOrder,
    });

    res.json({
      data: result.items,
      meta: {
        total: result.total,
        page: result.page,
        limit: result.limit,
        totalPages: Math.ceil(result.total / result.limit),
      },
    });
  });
}

// modules/vacancies/vacancy.service.ts
import { VacancyRepository } from './vacancy.repository';
import { CacheService } from '@shared/services/cache.service';
import { PaginatedResult, VacancyListItem } from './vacancy.types';

export class VacancyService {
  constructor(
    private readonly repository: VacancyRepository,
    private readonly cache: CacheService
  ) {}

  async getVacancies(params: GetVacanciesParams): Promise<PaginatedResult<VacancyListItem>> {
    const cacheKey = `vacancies:${JSON.stringify(params)}`;

    const cached = await this.cache.get<PaginatedResult<VacancyListItem>>(cacheKey);
    if (cached) return cached;

    const [items, total] = await Promise.all([
      this.repository.findPaginated(params),
      this.repository.countFiltered(params),
    ]);

    const result: PaginatedResult<VacancyListItem> = {
      items,
      total,
      page: params.page,
      limit: params.limit,
    };

    await this.cache.set(cacheKey, result, 300);
    return result;
  }
}

The contrast is stark. The legacy version had no validation, no caching, nested callbacks, string-concatenated SQL, and console.log as its only error reporting. The migrated version has Zod schema validation, a service layer with caching, typed repositories, and structured error handling — all running through the same API routes, invisible to clients.

Phase 3: Query Optimisation During Migration

Migration was not just code restructuring. I used each module migration as an opportunity to optimise underlying queries, auditing every SQL statement with EXPLAIN ANALYZE to identify inefficiencies.

// modules/vacancies/vacancy.repository.ts
import { BaseRepository } from '@shared/repositories/base.repository';
import { VacancyListItem, GetVacanciesParams } from './vacancy.types';

export class VacancyRepository extends BaseRepository<VacancyListItem> {
  async findPaginated(params: GetVacanciesParams): Promise<VacancyListItem[]> {
    const conditions: string[] = [];
    const values: unknown[] = [];
    let paramIndex = 1;

    if (params.sector) {
      conditions.push(`v.sector = $${paramIndex++}`);
      values.push(params.sector);
    }

    const whereClause = conditions.length
      ? `WHERE ${conditions.join(' AND ')}`
      : '';

    values.push(params.limit, (params.page - 1) * params.limit);

    return this.query<VacancyListItem>(`
      SELECT v.id, v.title, v.sector, v.location, v.published_at,
             c.name AS company_name
      FROM vacancies v
      INNER JOIN companies c ON c.id = v.company_id
      ${whereClause}
      ORDER BY v.published_at DESC
      LIMIT \({paramIndex++} OFFSET \){paramIndex}
    `, values);
  }
}

The legacy code selected SELECT * from tables with 30+ columns when the API response only needed 6 fields. The migrated queries selected only required columns, used proper indexing, and parallelised count queries with data queries using Promise.all.

Phase 4: Testing Strategy

Every migrated module shipped with comprehensive tests. I established a three-layer testing strategy:

// modules/vacancies/__tests__/vacancy.service.test.ts
describe('VacancyService', () => {
  let service: VacancyService;
  let mockRepository: jest.Mocked<VacancyRepository>;
  let mockCache: jest.Mocked<CacheService>;

  beforeEach(() => {
    mockRepository = { findPaginated: jest.fn(), countFiltered: jest.fn() } as any;
    mockCache = { get: jest.fn().mockResolvedValue(null), set: jest.fn() } as any;
    service = new VacancyService(mockRepository, mockCache);
  });

  it('should return cached result when available', async () => {
    const cached = { items: [{ id: 1, title: 'Engineer' }], total: 1, page: 1, limit: 50 };
    mockCache.get.mockResolvedValue(cached);

    const result = await service.getVacancies({ page: 1, limit: 50 });
    expect(result).toEqual(cached);
    expect(mockRepository.findPaginated).not.toHaveBeenCalled();
  });

  it('should query repository and cache on miss', async () => {
    mockRepository.findPaginated.mockResolvedValue([{ id: 1, title: 'Engineer' }]);
    mockRepository.countFiltered.mockResolvedValue(1);

    const result = await service.getVacancies({ page: 1, limit: 50 });
    expect(result.items).toHaveLength(1);
    expect(mockCache.set).toHaveBeenCalled();
  });
});

Test coverage across migrated modules went from under 15% to above 85%. This fundamentally changed deployment confidence — the team began shipping smaller, more frequent releases because they trusted the test suite to catch regressions.

The Results: Measured in Production

The migration was executed over a continuous period, with each module validated and fully deployed before moving to the next. Here are the production metrics we measured:

Metric	Before Migration	After Migration	Change
Average API response time	1.8s	320ms	82% reduction
Average query execution time	1.2s	480ms	60% reduction
Overall system performance	Baseline	+40% throughput	40% improvement
Daily API request capacity	~50,000 (strained)	50,000+ (comfortable headroom)	Stable at scale
Test coverage	<15%	>85%	5.7x increase
Deployment frequency	Bi-weekly	Multiple per week	3-4x increase
Production incidents (monthly)	6-8	1-2	75% reduction
New engineer onboarding time	~4 weeks	~1.5 weeks	63% reduction
Planned downtime during migration	—	Zero	No service interruption

The 40% performance improvement and 60% query time reduction were measured across the full platform using APM over a 30-day window after the final module was migrated.

Lessons for Engineers Facing Legacy Migrations

Here is what I would tell any engineer facing a similar challenge:

Never rewrite from scratch. The strangler fig pattern works. It feels slower than a rewrite, but is dramatically less risky. The business never stops.
Establish patterns before scaling. I spent two weeks building shared infrastructure and migrating one module as a reference. Every subsequent migration was faster because the patterns were proven.
Use the migration as a performance audit. Every legacy module contains hidden performance debt. Migrating is the perfect time to resolve it — you are already reading every line of code.
Type safety pays for itself immediately. The bugs caught by TypeScript during migration — latent in the JavaScript codebase for months — convinced even the most sceptical team members that strict typing was worth it.
Test coverage makes everything else possible. Without tests, every migration step is a gamble. With them, it is engineering.
Measure before, during, and after. Without performance numbers, the migration is a story. With them, it is evidence.

Final Thoughts

Migrating a legacy codebase is not glamorous work — no greenfield architectures to design, no new frameworks to evaluate. It is the painstaking work of understanding what exists, designing better versions, and replacing components one by one without breaking anything.

But it is some of the most impactful work an engineer can do. The VacancySoft platform now processes 50,000+ daily requests on an architecture that is maintainable, testable, performant, and ready for growth. The team ships faster, with more confidence, and new engineers become productive in days rather than weeks.

I have led this transformation from start to finish, and the lessons have shaped how I approach every codebase I work on — legacy or otherwise.

What legacy codebases taught me about real software engineering.

Thu, 12 Feb 2026 09:31:53 +0000

Almost every developer must've worked on at least one legacy project in their career.
And the first reaction is almost always the same.
You open the codebase and think,
"Who wrote this code?"
"Why is this such a mess?"
"I can do a lot better than this"
... something like this.
I too thought the same. And this reaction is justified. Because the first look is rarely pleasant. Confusing structure, outdated patterns, and code that feels impossible to reason about.
When I was first assigned to a legacy project, I wasn't excited at all.
It wasn't new, it wasn't shiny, and it definitely wasn't something I could show off. The codebase was large, the logic was spread across files, and even a small change felt risky. I kept wondering how anyone managed to build and maintain something like this.
It was a scary experience. For every small change, I've spent most of the time navigating the code than actually writing it. A lot of syntax actually felt unfamiliar to me. There was no package managers, no third party libraries, no proper documentation. Everything was written from scratch.
For a modern programmer like me, who uses third party libraries and packages for everything like it is normal, it definitely was a scary experience.
At first, everything felt difficult. Progress was slow and mistakes felt expensive. At some point, I even wondered, why aren't we migrating it to some new and shiny tech.
But as I spent more time navigating the codebase, reading, tracing, and understanding the processes, it started getting easier. I no longer felt lost every time I opened a file. I know where to look, which parts were fragile, and which ones could be changed safely. Debugging became faster, changes became more deliberate, and the fear of breaking things slowly faded away.
Working on legacy projects taught me many things. I no longer solely rely on third party libraries. I was realized package managers and libraries are good to have, but not necessarily needed. I got to know how systems actually work on ground level.
As I continued working on, I've started to admire the developers that built those systems decades ago, from scratch without any of the modern resources available to them. At first, I thought that the legacy developers only wrote messy code, but as time passes, I've started to appreciate the fact that they did their very best with the limited resources available to them amid tight deadlines and the effort they put into building everything from scratch.
Working on legacy projects made me a better programmer than I can imagine. It gave me the confidence to take up new challenges and work on new things. I am no longer afraid of working on things I don't know, because I am confident that I can learn.
Whenever I am assigned to legacy projects, I've started to look at them not as obstacles, but opportunities. Opportunities to learn more about complex systems and get used to the code of programming languages.
I no longer advise on migrating legacy projects into new stack. In fact, I advise against it. Because I believe that legacy projects are more stable than most of the project that are developed with modern tech stack.
For everyone who are working on legacy projects, I want to share some things from my experience.

Legacy projects are not obstacles for your career, but great opportunities for you to learn and grow.
Legacy projects are not outdated. They are just simple, boring and stable.
Legacy projects often lack good documentation, so when you are navigating through code, make sure to take notes properly. So that it may help you in the future or others who work on it.
When you came across tasks that couldn't be done using legacy stack, try to bridge that gap using modern stack. But don't actually try to migrate entire working system into modern stack, just because it's outdated.

Conclusion :
Legacy codebases changed the way I look at software engineering.
They taught me that good software isn't always clean or modern, but it's software that continues to deliver value overtime. More importantly, working on legacy stacks helped me become a better programmer and a better architect.
Understanding, maintaining, and improving systems that already exist is deeply rewarding. That's why, today, I genuinely enjoy working with legacy code.

JuggleBee’s Great Leap – Data Migration, ActiveStorage, and Production Readiness (Part 2)

Sun, 24 Aug 2025 10:52:32 +0000

Now that we had a deployable app, I set up a staging server using my new favourite provider, Hetzner (not a sponsor, lol), spun it up, and witnessed a “fully functional” skeleton of JuggleBee. Stage 1 of the migration plan was complete.

Now came the real meat and potatoes of the project — actually hydrating the new app with all of its production data. We’re talking over 50,000 images, countless database records, and security credentials… the works. This is the part where a missed step could mean broken listings, missing files, or downtime. No pressure.

In case you missed Part 1, we covered:

Why I started fresh on Rails 8 instead of doing incremental upgrades.

Migrating core models/controllers/services to modern Rails conventions.

Swapping Sprockets for importmaps and modernizing the JavaScript setup.

Replacing Sidekiq + Redis + whenever with ActiveJob + SolidQueue.

Moving deployments to Kamal 2 with Traefik and Let’s Encrypt.

Catch up on it here: JuggleBee’s Great Leap – Rebuilding a Rails 4 App in Rails 8 (Part 1)

Now—back to the post.

The Daunting Database Migration

Legacy JuggleBee had been coasting along happily on Postgres 9.6 — which, back in 2016, was the latest and greatest. Fast forward to today and it’s long past its sell-by date, with official support ending in November 2021. Upgrading wasn’t just about keeping up with the times; Postgres 17.5 brings some serious perks:

Native JSON field type support.
Incremental backups with pg_basebackup --incremental, slashing backup time and storage usage.
Noticeable performance gains from better memory management, indexing, and partitioning.
Improved observability via enhanced EXPLAIN options and richer stats views.
…and more.

It was a no-brainer to upgrade, but the version gap meant one wrong move could corrupt thousands of user, auction, and invoice records. That made reliable backups non-negotiable before touching a single byte. Luckily, I already had a manual backup process baked into my deploy routine. Here’s the script (feel free to steal any of the scripts in my posts):

#!/bin/bash

DB_CONTAINER=($(sudo docker ps | grep postgres | awk '{print $NF}'))
BACKUP_NAME=dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql
BACKUP_FOLDER=db_backups
KEEP=10

# Dump the database into a backup sql file
echo "Creating the database dump..."
docker exec -t $DB_CONTAINER pg_dumpall -c -U postgres > $BACKUP_NAME
echo "Database dump created."

echo "Moving database backup to backup folder..."
mkdir -p $BACKUP_FOLDER
mv $BACKUP_NAME $BACKUP_FOLDER
echo "Backup moved to backup folder."

echo "Deleting old releases..."
(cd $BACKUP_FOLDER && (ls -t | head -n $KEEP; ls) | sort | uniq -u | xargs rm -rf)
echo "Backup stored."

One catch: pg_dumpall (used above) tries to dump everything — including Postgres cluster-wide settings — which can be version-specific and cause headaches on import. For a major version jump, you want pg_dump, which targets a single database and avoids the version mismatch landmines.

For the migration, I only needed to change the docker command we executed - with the added ENV vars, that is:

DB_USER=db_user
DB_PASSWORD=db_password
DATABASE_NAME=database_name

# ...

docker exec -e PGPASSWORD=$DB_PASSWORD -t $DB_CONTAINER \
    pg_dump -U $DB_USER $DATABASE_NAME > $BACKUP_NAME

With the new backup in hand, importing into Postgres 17.5 went off without a hitch — no edits, no drama. Honestly, I was braced for a fight given the version gap, but the data was simple enough (and avoided fancy Postgres features) that it just… worked. A rare and pleasant surprise in a project full of moving parts.

Listing Image Migration

Unlike the data migration before it, migrating all the listing images (just shy of 50,000!) came with its own set of headaches. The legacy setup used CarrierWave with a custom uploader and fixed S3 paths, which worked fine at the time but wasn’t exactly future-proof. Since I was already upgrading to Rails 8, it made sense to tackle this technical debt head-on and move to ActiveStorage — effectively retiring these gems:

carrierwave
fog-aws
mini_magick

… and replacing them with image_processing for post-processing.

In the old days, uploads required creating an “Uploader” class and mounting it on a model. For example:

# app/models/image.rb
class Image < ActiveRecord::Base
  mount_uploader :aws, ImageUploader
end

# app/uploaders/image_uploader.rb
class ImageUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick
  storage :fog

  process resize_to_fill: [850, 850]

  version :thumb do
    process resize_to_fill: [280, 280]
  end

  def store_dir
    "listings/#{model.listing_id}/#{model.id}"
  end
end

With ActiveStorage, uploaders and hard-coded S3 paths are gone. You simply declare the attachment in your model (after setting up config/storage.yml):

class Image < ApplicationRecord
  has_one_attached :file do |attachable|
    attachable.variant :thumb, resize_to_limit: THUMB_DIMENSIONS, preprocessed: true
  end
end

That takes care of future uploads — but what about migrating the 50,000+ legacy images stored in the old bucket? The image.aws field plus CarrierWave’s store_dir gave me the exact file path to each image. I then wrote a script to:

Download each image from the legacy bucket.
Re-upload it through ActiveStorage so it generates its own hashed storage path.
Skip already-migrated images to allow safe re-runs.

Here’s the script in all its glory (run synchronously to avoid AWS rate limits — which meant a cool 4 hours of migration time):

#!/usr/bin/env ruby

require_relative '../config/environment'
require 'aws-sdk-s3'
require 'stringio'

OLD_S3_BUCKET = Rails.application.credentials.dig(:old_aws, :bucket)
OLD_S3_REGION = Rails.application.credentials.dig(:old_aws, :region)
OLD_S3_ACCESS_KEY_ID = Rails.application.credentials.dig(:old_aws, :s3_key)
OLD_S3_SECRET_ACCESS_KEY = Rails.application.credentials.dig(:old_aws, :s3_secret)

# Optional: skip already migrated images
SKIP_EXISTING = true

s3 = Aws::S3::Client.new(
  region: OLD_S3_REGION,
  access_key_id: OLD_S3_ACCESS_KEY_ID,
  secret_access_key: OLD_S3_SECRET_ACCESS_KEY
)

puts "Starting image migration..."

Image.find_each do |image|
  begin
    if SKIP_EXISTING && image.file.attached?
      puts "Skipping Image #{image.id} (already attached)"
      next
    end

    # Construct old S3 key from uploader logic - your path here
    key = "listings/#{image.listing_id}/#{image.id}/#{File.basename(image[:aws].to_s)}"

    obj = s3.get_object(bucket: OLD_S3_BUCKET, key: key)

    image.file.attach(
      io: StringIO.new(obj.body.read),
      filename: File.basename(key),
      content_type: obj.content_type || 'image/jpeg'
    )

    puts "Migrated Image #{image.id} (Listing #{image.listing_id})"
  rescue Aws::S3::Errors::NoSuchKey => e
    warn "Image #{image.id} missing in old bucket: #{key}"
  rescue => e
    warn "Failed to migrate Image #{image.id}: #{e.class} - #{e.message}"
  end
end

puts "Migration script finished"

Four hours later, we were in business — all images were now managed by ActiveStorage.
Future uploads are handled automatically, thumbnails are generated on demand, and the whole setup is cleaner and easier to maintain.

Credentials & Security

You might have noticed the use of Rails.application.credentials in the previous script. That’s new territory — Rails encrypted credentials didn’t exist back in 4.2.

Back then we had secrets.yml, which stored everything in plain text and was meant to be excluded from Git. In theory, you’d inject it during deploy with whatever tooling you used. In practice… I was lazy. My deploys were manual, the repo was private, and I just checked them straight in. Big no-no. Thankfully, Bitbucket never got hacked — but let’s just say this setup wouldn’t pass any kind of security audit.

Rails 5.2 introduced encrypted credentials — finally, a way to store secrets in plain text locally while Rails encrypts them with a master key. That master key stays out of Git and gets injected during deploy. Much better.

Fast forward to today, and Kamal (my de facto deployment tool) takes it a step further with built-in support for pulling secrets straight from password managers like Bitwarden, 1Password, or LastPass. That means my Rails master key, database credentials, and other environment variables can live safely in Bitwarden, and Kamal just grabs them during deploy. No manual copying, no “where did I put that key?” moments, and no plain-text secrets hanging around in the repo.

Here’s an example using Bitwarden via the CLI. This snippet fetches all secrets and assigns them to variables in .kamal/secrets:

SECRETS=$(kamal secrets fetch --adapter bitwarden-sm all)

KAMAL_REGISTRY_PASSWORD=$(kamal secrets extract KAMAL_REGISTRY_PASSWORD $SECRETS)
RAILS_MASTER_KEY=$(kamal secrets extract RAILS_MASTER_KEY $SECRETS)
POSTGRES_USER=$(kamal secrets extract POSTGRES_USER $SECRETS)
POSTGRES_PASSWORD=$(kamal secrets extract POSTGRES_PASSWORD $SECRETS)

The only catch: you’ll need to have the Bitwarden CLI installed and authenticated on every machine you deploy from. It’s a one-time setup, but totally worth it for the peace of mind of never having to worry about leaked secrets again.

Lessons Learned

Looking back, a few big takeaways stood out:

Scripts are your best friend. Whether it’s a database dump, image migration, or credentials setup, having a repeatable script means you can run it, tweak it, and run it again without reinventing the wheel. It also removes a ton of mental overhead when you’re juggling multiple moving parts.
Test migrations in staging — thoroughly. Moving to PostgreSQL 17.5 could have been a disaster if I’d gone straight into production. Running the full migration end-to-end in a safe environment gave me confidence and caught subtle issues before they ever touched live data.
Expect the cleanup phase. Even after the “big ticket” migrations were done, staging revealed a laundry list of smaller fixes — broken image links, JavaScript load order issues, outdated gem calls, and other gremlins. None of these were major individually, but together they took nearly two weeks to iron out. Build that buffer into your timeline.
Take the opportunity to ditch technical debt. CarrierWave, fog-aws, Sidekiq, Redis… all of these had served me well for years, but replacing them with ActiveStorage and SolidQueue means fewer dependencies to maintain, fewer services to monitor, and a cleaner architecture.
Security deserves equal billing with features. Rails encrypted credentials plus Bitwarden CLI integration finally dragged my secrets management into the modern age. No more plain-text secrets in Git. Enough said.
Modern Rails is worth the leap. From importmaps to Kamal, the tooling around Rails 8 makes deployment, scaling, and maintenance dramatically simpler than what I was doing in 2015.

Closing thoughts

And with that, JuggleBee officially joined the modern Rails era.

This wasn’t just a version bump — it was a full-stack rejuvenation.
The app runs faster, the infrastructure is leaner, and I finally have a deployment pipeline I can trust at 2 a.m. without crossing my fingers.

Was it worth skipping incremental upgrades? Absolutely. Starting fresh on Rails 8 gave me a clean slate to rebuild only what mattered, using tools that will keep JuggleBee humming for years to come.

If you’ve been sitting on a legacy Rails app, staring down the upgrade path and wondering if it’s worth the effort — it is. Just plan your migrations, test them in staging, and embrace the opportunity to shed some old weight while you’re at it.

JuggleBee’s now live on Rails 8 / Ruby 3.4.3 / PostgreSQL 17.5, with ActiveStorage handling thousands of images, Bitwarden keeping our secrets safe, and Kamal making deployments a one-command affair.

Now it’s time to step away from the terminal, grab a cold beer, and actually enjoy the thing I’ve been rebuilding over the last month — until the next big upgrade comes along.

Primum nil nocere in PHP: First, Do No Harm

Fri, 22 Aug 2025 07:17:09 +0000

Doctors have a saying: primum nil nocere — “first, do no harm.” I first heard it in a medical context, but it stuck with me. Could the same principle apply to programming? Absolutely — especially when working with legacy code.

If you work on legacy applications, you quickly learn one truth: every change can have unexpected side effects. The architecture is rigid, the design outdated, and the smallest tweak might break something miles away in the codebase. Still, we all want to make things better today than they were yesterday.

That’s why I wrote a pre-commit Git hook to apply the do no harm principle to my daily development. The idea is simple:

The whole codebase is under Git.
Every commit should meet the current coding standard (PSR-12 in my case).
Running PHP_CodeSniffer on the entire legacy project is slow and noisy.
So instead, I only check the lines I’ve actually changed.

If my changes violate the standard, the commit fails until I fix them. Over time, this improves the codebase without drowning me in thousands of old warnings.

Sometimes, I can’t fix a file immediately because of other existing violations. In that case, the hook can just warn instead of blocking the commit, letting me decide what to do. You can also extend the script with your own rules — the setup is entirely yours.

Each time you commit, you’re leaving the codebase a little cleaner, a little better. It’s like a doctor treating a patient: you’re not curing every illness at once, but you’re making sure you don’t make things worse.

The script is in my repository — take it, use it, adapt it. And remember: even in PHP, first, do no harm.

JuggleBee’s Great Leap - Rebuilding a Rails 4 App in Rails 8 (Part 1)

Thu, 21 Aug 2025 08:06:05 +0000

JuggleBee was born in 2015. It was Namibia's first online auction platform and is still one of the biggest today. I built it with Ruby on Rails 4.2 on Ruby 2.2. It sat there, rock-solid and stubbornly stable, only needing the occasional dust-off and minor tweak over the years. At various points in time, I thought about upgrading the various versions; however, I was stuck between a rock and a hard place — in order to upgrade Ruby, I had to upgrade Rails, and vice versa. The idea of incremental upgrades felt like a nightmare — two battlefronts to fight on, Ruby on one side and Rails on the other.

Fast forward to 2025. With the arrival of my daughter, I acquired a smattering of free time interspersed with sleepless nights. The perfect time to finally bite the bullet, bring JuggleBee into the 21st century (you know what I mean), and get these upgrades done. After much pondering and planning, only one realistic option remained... incremental upgrades would take months with constant patching between every version bump; I would have to take the leap from Rails 4.2 straight to Rails 8, with Ruby hopping from 2.2 to 3.4.3. It was quite the journey, and what follows is a breakdown of the challenges and learnings I made along the way.

Starting Fresh

Not to blow my own horn or anything, but I was in a pretty good place with this migration plan. The codebase of JuggleBee was intentionally built with self-contained business logic components, defining a clear separation of concerns. The models and controllers were not overly bloated, with liberal usage of "service objects" performing the more complicated logic, and an added separation of logic between my controllers and views using the "view decorator" pattern. This architecture made the copy-pasta approach almost… dare I say… fun. But let’s not kid ourselves — a jump from Rails 4.2 to 8 is no walk in the park.

As part of the rails new process (after installing the latest Ruby and necessary Rails gems), and before the true code migration could begin, I just needed an empty, runnable project with the necessary gems installed. I appended my old Gemfile with the auto-generated one, removing all locked versions to ensure the latest compatible versions were installed. I also identified irrelevant and dead gems, removing those and replacing them with alternatives where necessary (more detail on this later).

Reading into each of the default gems specified by the rails new generator gave me a good understanding of what the current Rails stack looks like. I didn’t need all of it, so some were commented out, but I did take some of the new suggestions into account. Puma, for example, replaced Unicorn, which I was previously using. I could also get rid of God, in the non-divine sense, as I no longer needed to monitor my server state manually. All in all, this whole process didn’t take more than an hour or so.

Models, Controllers, Services & Views (in that order)

These being purely Ruby code made it the easiest place to start. Even though we jumped up from Ruby 2.2 to 3.4.3, not all that much in the core language changed. Twas Rails that was the most behind. For example, JuggleBee was developed before the abstract ApplicationRecord class made its way into the Rails architecture!

Models

The models were the easiest to migrate over, as they already had a smattering of unit tests behind them. First, though, we had to get the database up and running. Spoiler alert: I was also updating our Postgres version from 9.6 to 17.5 as part of this big update. The old migration files were fossils — brittle, outdated, and utterly unfit for a modern Rails 8 app. The simplest solution was to drop a pg_dump of the current database (just on my local copy of the now legacy JuggleBee) and import it, generating the schema.rb. I could now copy across my models and test them out in the rails console.

Some of the updates required to get things up and running were:

belongs_to is now a required atribute. I have a home-grown version of polymorphism which allows a Listing to be either a Product or Auction and the belongs_to on these associations are optional, so I had to update these associations accordingly (*side note: a refactor waiting to happen*). So,
```
belongs_to :auction
belongs_to :product
```
becomes
```
belongs_to :auction, optional: true
belongs_to :product, optional: true
```
I had a couple of instances of update_attributes (very selective. Given they bypass validations, they were used with extreme caution) which is now deprecated and had to be changed to update.
Deprecated validation methods such as validates_presence_of :name needed updating to validates :name, presence: true sort of changes.

As for the views, the gems I used (haml-rails, redcarpet, simple_form, cocoon, etc) are all still actively maintained and required no changes at all — a very pleasant surprise.

Controllers

Next up were the controllers. Thanks to my use of service objects for the bulk of complex logic, migrating controllers was mostly painless. Rails 8 is stricter, and that’s where most of my changes were required. While bringing over controllers, I also began migrating the service objects they called upon, which are POROs and required almost no changes.

The main updates included:

Params passed to background jobs now must be valid JSON. This was especially relevant for controllers triggering email or background tasks.
Controller filters were renamed to actions (before_filter → before_action).
Controller hooks like before_action should come after the method they reference, not at the top of the file (a style guideline enforced in modern Rails apps).
redirect_to :back was replaced with redirect_back fallback_location: root_path (or an appropriate fallback path).
The responders gem is no longer included in Rails, so respond_with calls were rewritten using respond_to blocks.

All in all, the MVC migration was more about cleaning things up and embracing modern Rails conventions rather than fighting major incompatibilities.

JavaScript Modernization

This is where things started to get spicy — the kind of spicy where you wonder if you just bit off more than you can chew. So much has changed in the front-end assets side of things. JuggleBee leverages jQuery (thankfully I dodged the CoffeeScript bullet) with Sprockets as the asset pipeline. Modern Rails favours importmaps as the default asset manager and pipeline, and keeping with the spirit of rejuvenating JuggleBee and bringing it up to speed, I signed up to it too. This allowed me to replace a bunch of gems which added various front-end features, such as chartkick, masonry and bootstrap with the importmaps pin alternative. Some libraries had to remain as CDN imports in my layout file, due to the order at which these JavaScripts got initialized and loaded by the DOM.

My suite of JavaScript classes also needed a bit of love and attention. The Sprockets

//= require

statements were replaced with

import

and my classes now had to export themselves so that they could be loaded as ES modules. All the files had to be relocated from app/assets/javascripts/ to app/javascript/. The way we add our JavaScript base file into our application view layout also had to change slightly, going from

<%= javascript_include_tag "application" %>

<%= javascript_importmap_tags %>

Even though jQuery is considered a bit long in the tooth, given the plethora of really solid UI frameworks like Vue and React, I opted to keep my reliance on it for the time being. It still works, is actively maintained, and trying to replace it now would be a whole new kettle of fish. An adventure for another day.

Background Jobs & Scheduling

This area was one of the biggest wins in the entire migration. JuggleBee had the “classic” background processing setup: Sidekiq + Redis + whenever (for cron). It worked fine for years, but it always felt a little… heavy, like lugging around a toolbox just to tighten a single screw. Sidekiq required its own container, Redis was a hungry beast that always felt like it was asking for more memory, and whenever meant fiddling with cron jobs and ensuring everything stayed in sync across deploys. It worked, but it was yet another moving part in an already aging stack.

Enter SolidQueue — a gem that ships with Rails 8, built to replace Sidekiq-like setups with something that is both simpler and more tightly integrated with ActiveJob. The real beauty? No Redis. SolidQueue uses the same database you already have (Postgres in our case) to manage job queues, which meant I could drop an entire service and reclaim a chunk of server memory.

Here’s what this meant for JuggleBee:

No more Sidekiq configuration, container management, or Redis headaches.
The whenever gem (used for cron scheduling) could be thrown out too, thanks to SolidQueue’s built-in recurring.yml.
Background jobs now feel like a natural part of Rails — no extra glue required.

To put it in perspective, my stack went from:

Rails App + Sidekiq + Redis + whenever + cron

to:

Rails App + SolidQueue

That’s it. Beautiful, minimal, and a lot less to maintain.

Another chef’s kiss moment was how little code I had to change. Most jobs migrated over with minimal tweaks — the biggest adjustment being that job arguments must be JSON-serializable. This meant replacing keyword arguments with hashes like:

EmailJob.perform("MyEmailClass", {"from" => current_user.name, "subject" => "Hello there"})

instead of:

EmailJob.perform("MyEmailClass", from: current_user.name, subject: "Hello there")

It was one of those rare upgrades where less really is more. Dropping Redis and cron alone made this whole migration feel worth it.

Infrastructure & Deployment

For years, deployment was powered by a custom shell script I wrote. It wasn’t flashy, but it was reliable and got the job done. It handled atomic releases, cleaned up old deployments, built Docker images, restarted containers, and even maintained a cache for faster updates. For a single-developer project like JuggleBee, it was the perfect balance of simplicity and control.

Here’s the core of that script:

#!/bin/bash

branch=${1:-master}
cwd=/home/ubuntu
repo_url=your_repo_here
revision=master
keep=5
timestamp=$(date +%s)
cache=$cwd/.git_cache
releases=$cwd/releases
mkdir -p $releases
previous=$releases/$(ls $releases/ -t | head -n 1)
release=$releases/$timestamp

if [ ! -d $cache ] ; then
        git clone $repo_url $cache
fi

echo "downloading latest source code from $branch..."
mkdir -p $release
(cd $cache && git gc --prune=now && git remote prune origin && git fetch origin && git reset --hard origin/$branch && git archive $revision | tar -x -c $release)

echo "release timestamp is: $timestamp ($release)"

echo 'building docker images...'
/bin/bash -c "(cd $release && docker compose -f docker-production.yml build)"

if [ $? -eq 0 ]
then
        if [[ $previous != "" ]] ; then
                echo 'stopping previous containers...'
                /bin/bash -c "(cd $previous && docker compose -f docker-production.yml stop && docker ps -a -q --filter='status=exited' | xargs docker rm)"
        fi

        echo 'restarting application...'
        /bin/bash -c "(cd $release && docker compose -f docker-production.yml up -d)"

        echo 'deleting old releases...'
        (cd $releases && (ls -t | head -n $keep; ls) | sort | uniq -u | xargs rm -rf)

        echo 'creating symlink.'
        rm $cwd/current-release
        ln -s $release $cwd/current-release

        echo 'deploy complete.'
fi

Honestly, this script could have kept soldiering on for years… until Kamal walked in like the cool new kid who makes your old tricks look ancient. It wasn’t broken — far from it — but Kamal is like having a personal DevOps engineer in your terminal. It takes all the things I cared about (Dockerized deploys, atomic releases, rollbacks) and adds extra superpowers I didn’t even realize I needed.

Introducing Kamal 2

Kamal is a server provisioning and deployment tool built specifically (but not limited to) Rails apps. It automates a ton of tasks that my script didn’t — and one of the most significant changes? No more Nginx.

Kamal ships with a built-in Traefik proxy that handles all your routing and SSL certificates out of the box. No more tinkering with nginx.conf files or restarting a separate webserver. One less dependency chewing through RAM and one less thing to break at 2 am.

Here’s what Kamal brings to the table:

kamal setup: installs Docker, Git, and all required dependencies on your server.
kamal deploy: builds your Rails app into a Docker image, pushes it to your registry, and runs it on the server.
Traefik proxy with SSL (via Let’s Encrypt): you get HTTPS without lifting a finger.
Accessory management: want Postgres or Redis? Kamal spins them up as Docker containers.
Scaling: need more capacity? add another container in deploy.yml and Kamal will route traffic automatically.

The impact of this was huge. I went from managing Docker builds, old release directories, and an Nginx webserver, to just running one command. There’s something almost unsettling about how smooth it is — I felt like I was missing steps at first, like forgetting my keys when leaving the house.

Wait, that’s it? Did I actually deploy? Did I forget something? Oh… it’s done already. Huh.

This wasn’t just a convenience win — it was a dependency detox. Between dropping Nginx here and killing Redis with SolidQueue earlier, my infrastructure got a lot lighter, faster, and cheaper to run. Kamal didn’t just evolve my old script — it rendered half of its logic unnecessary.

Half Way There

With the new Rails 8 foundation in place, JuggleBee has already shed a lot of its old skin. We’ve modernized the models and controllers, swapped out a creaky asset pipeline for importmaps, retired Sidekiq, Redis, and cron in favor of SolidQueue, and traded a homegrown deployment script (solid as it was) for the convenience and power of Kamal 2. The app is lighter, faster to deploy, and much easier to maintain — but we’re not done yet.

Getting the Rails 8 app running and deployable was only half the battle. Now comes the rest of the journey:

Migrating data from a legacy PostgreSQL 9.6 database to a fresh PostgreSQL 17.5 instance.
Replacing CarrierWave with ActiveStorage and migrating all user-uploaded files into a new S3 bucket.
Locking down credentials with Rails encrypted secrets and Bitwarden CLI.
Cleaning up leftover code smells, finalizing test coverage, and polishing the overall performance of the new stack.

That’s some of what Part 2 will cover — all the finishing touches, the unexpected hurdles, and the final steps that took JuggleBee from a Rails 4 relic to a lean, modern, and production-ready Rails 8 app.

Stay tuned for Part 2, where the migration story continues.

While everyone’s chasing AI and Data Science… COBOL is quietly running the world.

Thu, 07 Aug 2025 14:04:08 +0000

You’ve heard the stat: COBOL powers 95% of ATM transactions — but that’s just scratching the surface.

The real story? COBOL is everywhere:

→ 85% of insurance claims are processed using COBOL
→ Major airline reservation systems still run on it
→ U.S. military missile defense? COBOL.
→ Social Security handles 250M+ records daily — with COBOL

And yet, it’s not talked about — because it just works.

Here’s the surprising truth:

COBOL isn’t outdated. It’s battle-tested, high-performance, and ultra-reliable:

• 220+ billion lines of active code
• $3 trillion processed daily
• Systems with 30+ years of uptime
• Powers 95% of global ATM swipes

Failed modernizations prove the point:

– One bank lost over $100M trying to replace COBOL
– Another gave up after 7 years of migration hell
– An insurer lost decades of customer data

So, why does COBOL persist?

99.999% uptime – almost never fails

2M+ transactions/sec – unmatched speed

50+ years of security hardening

Mathematical precision – critical for finance

While the tech world obsesses over the next big thing, COBOL remains the unshakable foundation of global finance.

Sometimes the most important technology...
is the one that’s already doing the job better than anything else.