izilaw, takeover and redesign of the Django legal appointment platform

A Django platform to be updated

About izilaw

izilaw is a French platform for online appointments with legal professionals: lawyers, notaries, and judicial officers. Individuals can compare profiles, see the cost of the first appointment, and book a time slot; professionals manage their schedules, synchronized with Google Calendar or Outlook, their quotes, their service notifications, and their invoices. Over 27,000 pages are served by a custom-developed Django application since 2017, hosted on Heroku, supplemented by a practical guide.

Why contact us

After several years without major updates, the platform could no longer be updated: Heroku no longer supported the Python version it was based on, and its Django version, 1.11, refused to run on a newer version. The izilaw team was looking for a provider capable of taking over this code alone, as the original developers had left, bringing it up to current standards, and then evolving it: security, compliance, design, content. A technical support project carried out in three phases, from August to October 2026.

Objectives and key features

First, regain the ability to deploy without breaking a service used daily. Then, make updates safe and routine, so as never to accumulate nine years of backlog again. Finally, offer the platform a modern, fast, and accessible interface, and entrust the practical guides to WordPress, which the team can update without a developer.

Challenges and constraints

The code had no automated tests and little documentation. The workflows are numerous and sensitive: six user profiles, payments, PDF invoices, synchronized calendars, appointment pages integrated as white-label on partner firm websites. Each modification therefore had to be proven without regression before reaching production, and the platform had to remain online throughout the intervention.

Project steps

Version upgrade: from Django 1.11 to Django 5.2 LTS

A safety net before touching the code. Due to the lack of tests, we first wrote a tool that photographs the site page by page (response code, document structure, visible text, forms, links, images), on a local copy under Docker with PostgreSQL 17. This snapshot, taken from the old version, served as a reference at each stage.

Two inseparable, monolithic upgrades. Python goes from 3.9 to 3.12, and Django from 1.11 to 5.2 LTS, maintained until April 2028. Four major Django versions crossed at once: routes rewritten in 14 files, 32 foreign keys explicitly defined without changing the schema, authentication views and file storage moved to current APIs. Deployment shifts to the Heroku container stack. Result: 44 out of 44 pages identical to the reference, and a platform deployable once again.

Industrialization: safe updates and tests everywhere

Frozen dependencies and a one-command update. The 112 Python components are locked down to the exact version. A single command chains updates, rebuilds, checks, tests, and before-and-after page comparisons; Dependabot suggests security patches, and GitHub continuous integration verifies every change. Five abandoned components have been replaced, including the CKEditor 4 editor with TinyMCE 7 and the old Google Calendar connection with the current official library.

From zero to 1,668 automated tests. They cover the essential workflows (appointment booking, quotes, service notification, payment, invoices) and simulate external services, so that no test sends real emails or calls real APIs. Scans visit all site pages under six profiles, checking every internal link and every referenced file. This safety net allowed us to move quickly afterward while deploying with confidence: it blocks any production release as long as even one test fails.

A cleaned-up platform. Integrations that were no longer used (old partners, payment provider, ad tracker) are removed along with their tables. Libraries loaded from four third-party servers are now served by izilaw.fr. A comprehensive security review accompanied these efforts, with login attempt limits, security HTTP headers, and email authentication (SPF, DKIM, DMARC). The domain is placed behind Cloudflare, an automatic attachment purge, set to their retention periods, is in place, and Google geocoding is cached to reduce billed calls.

Front-end redesign: from Bootstrap 3 to a custom design system

The foundation first. Bootstrap 3.3.7 and jQuery give way to Bootstrap 5.3.8: 82 Django templates, nearly 1,200 grid classes, and 458 icons converted, with icons moving from a font to an SVG sprite limited to the pictograms used.

A complete redesign. A documented design system retains the logo's colors and adopts Atkinson Hyperlegible Next, a font designed for readability. Seventy-seven mockups, reviewed for existing coverage, accessibility, and navigation, cover public pages, appointment and quote funnels, professional and client areas, error pages, and emails. On mobile, a professional's profile displays their identity, four time slots, and the booking button from the very first screen.

Performance-focused integration. The redesigned pages do without jQuery; each loads a single stylesheet and a critical inline stylesheet under 7 KB compressed. Photographs are served in AVIF, Google Maps only loads on first use of the address field, and the 53 transactional email templates adopt the same branding, in HTML and text. Mockups were compared side-by-side with the final rendering at 375 and 1,280 pixels wide.

Integration with WordPress: a guide for content

Every tool in its place. Django remains in charge of application-specific features (search, profiles, appointments, connected areas); the 143 practical guides are moved to the Guide, a WordPress site using GeneratePress and GeneratePerf, where the editorial team writes and updates them independently. The two sites share the same branding and header: for the visitor, they are one.

A custom WordPress extension. It declares the content type for the profiles, exposes the Guide's structure so that the Django application's menus remain synchronized (with a backup in case the Guide is unresponsive), and schedules expiration: each profile is assigned an update date, flagged to the team in the administration and via a monthly email. The switch was made without any loss of SEO: 143 permanent redirects, 209 internal links rewritten to their final address, each step repeated on a test server before production.

Intervention Report

Each batch was validated in pre-production before being proposed for production, along with its rollback procedure. Two reports detail, item by item, what was done, how it was verified, and what remains to be decided, and a timestamped log tracks each action. The izilaw team thus has a documented platform that they can entrust to any Django developer in the future.

Taking over a legacy custom application

Can a Django application be modernized without a complete rewrite?

Yes, and it’s often the best choice. The izilaw code had nine years of proven business rules: rewriting it would have cost months and reintroduced already fixed bugs. A methodical version upgrade, backed by a non-regression safety net, preserves this capital and updates the foundation in a few weeks.

Why combine WordPress with a Django application?

Because each excels in its domain. Django handles application logic, accounts, and payments; WordPress offers content creators a familiar editor, revision history, and a proven SEO ecosystem. Connecting the two with a plugin and a lightweight API avoids redeveloping a CMS within the application and frees developers from content requests.

Which provider to choose to take over a Django, Python, or Heroku application?

A provider who masters the technology, but above all the method: measure before acting, secure every change with tests, deliver in verified batches, and document. This is how we work, regardless of the technology, from a Python application on Heroku to a Shopify store, a Drupal site, or PrestaShop. If your custom platform is no longer keeping up, our redesign and technical support services are made for it.

The technical stack

The result in numbers

PageSpeed Insights measurements on mobile, before and after the redesign went live; test suite executed on the production version.

Homepage: score from 94 to 98.5, weight from 1,005 to 199 KB. Search: score from 73 to 98, largest contentful paint from 8.0 to 2.3 s. Login: score from 73 to 99.5, layout shift (CLS) from 0.78 to 0. On the redesigned pages, accessibility measurements at the three screen widths no longer show any defects. The platform runs on Python 3.12 and Django 5.2 LTS, maintained until 2028.

Does your custom application deserve the same treatment? Discover our technical support.

The rest and conclusion in images