For me, that work was ticket triage.

I work with a small engineering team of five developers maintaining a multi-tenant SaaS product used by many customer organizations. On an average day, we receive six to seven new items: bugs, feature requests, data requests, tech-support requests, and small enhancements.

The support team would create a ticket and then ping me to assign it to a developer.

One assignment was easy.

The hard part was doing this repeatedly while keeping the whole team’s workload in my head.

Who is already handling a priority bug? Who has a large task due tomorrow? Who has work waiting for review? Who can realistically take one more ticket today? Is this new item urgent enough to interrupt someone? What due date should I set?

I tried solving this manually. I maintained a small spreadsheet where I noted who was working on what and when each developer might be free.

But soon the spreadsheet became another system to maintain.

Every support ping caused a context switch. It interrupted the work I actually wanted to spend more time on: planning, product thinking, and building new features.

Eventually, I reached a point I am not proud of. I started ignoring some of the frequent calls and messages asking me to assign tickets.

That was the signal that the process needed to change.

Not because I needed to make faster manual decisions.

Because I needed to encode the decision-making system itself.

The goal

I did not want to build a flashy AI demo.

I wanted a system that could quietly run during working hours and do the boring but important work:

• review newly created tickets

• understand their priority and type

• look at the current workload of each developer

• assign the ticket fairly

• set a reasonable due date

• leave an explanation behind

• fail safely if anything goes wrong

The system currently runs every 30 minutes between 9 AM and 6 PM, Monday to Friday, on an old laptop at home.

That schedule is intentional.

I did not need real-time assignment. I needed tickets to sit in triage for at most 30 minutes so the support team would not feel the need to ping me manually.

After about two weeks, the system had triaged roughly 80–100 tickets. I still review decisions from time to time, but I rarely need to manually assign tickets now. The pings and calls have almost gone silent, and the average time between ticket creation and assignment has improved dramatically.

Why I did not just ask an LLM to assign tickets

The obvious AI solution would be:

Give the LLM all open tickets, all developers, all priorities, and ask it to pick an assignee.

I deliberately did not do that.

There were a few reasons.

First, developer assignment is not just a language understanding problem. It is a scheduling and fairness problem.

A developer might already have 9–10 tasks assigned for the coming week. New tickets are added throughout the day. If I fed the full workload context to the LLM every 30 minutes, the prompt would become large, noisy, and unreliable.

Second, I wanted the system to be explainable.

If the automation assigned a ticket to someone, I wanted to know why. I wanted to inspect the score. I wanted to tweak the formula. I wanted to run dry-runs and compare decisions before allowing the system to make real changes.

That is much easier when Python makes the final decision.

Third, this started as a personal project to reduce my own operational load. I did not want to spend paid AI tokens on something that needed to run every 30 minutes, five days a week.

So I used a local LLM only where it made sense: classifying the ticket.

The principle became:

LLM: classify the ticket
Python: assign the ticket
Humans: handle ambiguity and product judgment

That separation made the system much more reliable.

The LLM handles judgment-heavy interpretation of a title and description. The deterministic code handles workload, fairness, due dates, and operational safety.

The architecture

At a high level, the system has three layers.

Layer 1: LLM classification
Layer 2: Deterministic workload and scheduling
Layer 3: Safety, auditability, and retry behavior

The end-to-end flow looks like this:

New ticket in Triage
        ↓
Read title and description
        ↓
Compute each developer's current workload
        ↓
Local LLM classifies priority/type/area/effort
        ↓
Python scores developer + due date candidates
        ↓
Assign ticket and set due date
        ↓
Post auto-triage explanation
        ↓
Move ticket to the next workflow stage

The local LLM classifies each new ticket into structured metadata:

{
  "priority": "P0 | P1 | P2 | P3",
  "type": "bug | feature",
  "area": "backend | frontend | data | payments | reports | unknown",
  "effort": "small | medium | large",
  "confidence": 0.0,
  "reasoning": "Short explanation"
}

The assignment logic then uses that structured output to decide who should get the ticket and when it should be due.

The important part is that the LLM does not assign the ticket directly.

It turns messy human-written ticket text into structured input. The scheduling system does the rest.

Running it on an old laptop with Ollama

I run this on an old laptop at home.

That laptop was already acting as a small home server for a few self-hosted services. So adding this automation there had very low friction.

I use Ollama with a small local model. The model does not need to be brilliant at everything. It only needs to be good enough at one narrow task: reading a short ticket title and description, then classifying the ticket into priority, type, area, and effort.

That constraint matters.

A small local model is not something I would trust to run a large planning process with a long context window and many moving parts. But for narrow classification with a tight prompt and structured output, it works well enough.

Latency is also acceptable. Since the script runs every 30 minutes, it usually processes only a few new tickets at a time. It does not need to respond instantly like a chat interface.

This setup also has one practical advantage: it runs even if my main computer is off, or if I am away from my desk.

The goal was not to build the most powerful AI system.

The goal was to build one that would quietly run every working day without asking for my attention.

Workload is not the number of open tickets

The first real design challenge was workload.

A naive system might count how many open tickets each developer has and assign the next ticket to the person with the lowest count.

That does not work.

Five tiny UI issues are not the same as one production-blocking bug. A developer handling a burning priority issue should not be treated as equally available as someone working on a few low-priority enhancements.

So the system calculates weighted workload.

Conceptually, each ticket contributes workload like this:

workload = priority_weight × effort_weight × type_multiplier

Priority matters because urgent work consumes more attention.

Effort matters because large tasks should count more than small tasks.

Type matters because bugs and features behave differently. Bugs usually cannot wait. Features often can.

For example, a high-priority large bug should significantly increase a developer’s workload score. A small low-priority enhancement should count much less.

This means the system does not ask:

Who has the fewest tickets?

It asks:

Who has the least meaningful active workload?

That difference is important.

Developers in our team handle a mix of bugs and features. If a developer has more feature-related work, the system can still assign them an urgent bug, because feature work is more interruptible than bug work.

This is one of the places where keeping the assignment logic outside the LLM paid off.

I arrived at the formula through many trial runs. Whenever an assignment felt unfair, I could inspect the score breakdown, adjust a weight, run a dry-run, and see how the decision changed.

The system became tunable like a scheduling algorithm, not mysterious like a prompt.

Not all open work is equal

Our tickets move through a Kanban-style workflow:

Triage → Figuring it out → In Progress → For Review → For Verification → Done

A ticket may be open, but that does not always mean the developer is actively working on it.

This became an important part of the workload model.

For example, once a developer has submitted a pull request, the ticket moves to For Review. At that point, most of the implementation work is done. There may still be changes requested, but the developer is usually not spending full active effort on it.

So the system counts For Review tickets as half workload.

Once the PR is merged, the ticket moves to For Verification. At that stage, the code is done and the ticket is waiting for QA, deployment, or closure. I do not want that ticket to count against the developer’s workload anymore.

So For Verification counts as zero workload.

Conceptually:

This small detail made the assignment logic much fairer.

A ticket waiting on another person should not fully block the developer who already did the work.

Handling stale tasks

Another real-world issue was stale work.

In a SaaS product used by many customer organizations, not every request has the same urgency. Some requests are logged because they need to be recorded. Some are low priority. Some do not fit the current roadmap. Sometimes the customer who requested the change stops following up.

But the ticket still exists, and it may still have an owner.

In the first version, the system counted all assigned open tickets as active workload. That caused a problem.

If one developer had many old assigned tasks that had not seen activity for a long time, the system treated them as overloaded. As a result, newer tickets were unfairly assigned to others.

That was technically consistent, but operationally wrong.

So I added a configurable workload lookback window. Recent assigned work counts toward workload. Future-due tasks still count even if they are older. But old likely-stale tasks are not treated as active workload forever.

At the same time, I did not want to completely ignore stale work. A large pile of old assigned tickets is still a signal that the person’s queue is not clean.

So the system applies a small capped stale-task penalty.

The tradeoff is:

Do not count stale tasks as real active work.
Do not pretend they mean nothing either.

This was one of the more useful lessons from building the system: workload is not a static number. It depends on recency, ownership, workflow state, and due dates.

Fairness across runs

The first version of the system sometimes assigned too many tickets to the same person across separate runs.

When I investigated, the decisions were often justifiable. That developer had a slightly lower workload score.

But that exposed a different problem.

The system does not only need to be fair. It also needs to look fair to the humans using it.

If the same person keeps getting assigned new tickets repeatedly, it feels unfair, even if the score says they are technically the least loaded.

This is especially important for a cron-based system.

A single run may be fair in isolation. But several fair-looking runs can become unfair across a day or week.

So I added recent-assignment fairness.

The system keeps a compact history of recent AI assignments. Developers who received AI-assigned tickets recently get a penalty in the score. Assignments today get a stronger penalty. Assignments within the current run also affect the score, so one run does not dump all new tickets onto the same person.

There is also a close-score fairness rule.

If two developers are close enough in score, the system can prefer the person who has received fewer recent AI assignments.

The principle is simple:

When two candidates are close enough, fairness should beat a tiny score difference.

This made the system behave better from a human perspective.

It still respects workload. It still respects urgency. But it avoids repeatedly choosing the same developer just because their score is slightly lower.

Due dates: urgency plus capacity

The system does not only assign a developer. It also assigns a due date.

Due dates are internal planning dates, but we treat them as deadlines. So the scheduler has to balance urgency with realistic capacity.

The priority model works roughly like this:

A P0 burning issue is treated differently from everything else. It gets today’s due date and goes to the least-loaded suitable developer. It bypasses normal day-by-day capacity checks because urgent production issues cannot wait for a perfect schedule.

There is still a safety cap so one developer is not silently buried under unlimited same-day P0s.

P1 is urgent too, but less extreme. It is scheduled soon and respects working days.

P2 and P3 tickets go through capacity-based scheduling.

Instead of assuming a developer is unavailable until their latest due date, the scheduler treats each day as having capacity slots. For example, the system can allow multiple smaller bugs per developer per day, while being more conservative with feature work.

This matters because modern development work is not always one large task at a time. Developers may be able to handle multiple small bugs in a day, especially with AI-assisted coding tools.

The scheduler considers:

• current open workload

• ticket priority

• effort

• type

• target-day load

• due-date delay

• recent AI assignments

• current-run assignments

• area match

• stale-task penalty

The lowest score wins.

The final assignment is therefore not just:

Who is free?

It is closer to:

Who is the fairest available person for this specific ticket, on the earliest reasonable due date?

Dry-runs became part of the design process

Dry-run mode was essential.

Before allowing the script to make real changes, I used dry-runs extensively. A dry-run would show what the system would classify, who it would assign, and what due date it would choose, without actually modifying anything.

This helped me tune the system safely.

For example, if an assignment looked wrong, I could check the score breakdown:

open workload component
bug count component
target day load component
due date delay component
recent assignment component
stale task penalty
skill or area bonus
final score

That made the system debuggable.

Without score breakdowns, I would have been guessing. With score breakdowns, I could see exactly why the system picked someone.

Dry-run mode was not just for safety.

It became the way I designed the algorithm.

Failing safely

For this kind of automation, doing nothing is often safer than doing the wrong thing invisibly.

So the system is designed to fail safely.

If classification fails, the ticket remains in triage.

If the assignment write fails, the ticket remains in triage.

The next cron run can retry.

The system also has fallback behavior for classification. If the local LLM returns malformed output or fails, a deterministic heuristic classifier can produce a conservative low-confidence classification instead of silently breaking the run.

When a ticket is assigned successfully, the system posts an auto-triage comment with the classification, reasoning, assignee, due date, and any instructions.

This visible comment matters.

It turns the automation from a black box into something the team can inspect.

What I deliberately did not automate

I currently automate assignment for bugs, tech-support tickets, data requests, small enhancements, and small features.

I do not want the system to own large product decisions.

Big features still go through me. They need proper discovery, a Problem Discovery Report, and a PRD before being assigned to someone.

That boundary is important.

The system is allowed to assign ownership.

It is not allowed to decide product direction.

This keeps the automation useful without making it dangerous. It removes repetitive triage work, but it does not replace human judgment where ambiguity, customer impact, architecture, or product direction is involved.

Results after two weeks

After around two weeks, the system had triaged roughly 80 tickets.

The biggest improvement is not just the number of tickets assigned. It is the reduction in interruptions.

Before this, the support team frequently pinged or called me to assign tickets. Now those pings have almost gone silent because every new ticket waits at most 30 minutes before the automation picks it up.

The average time between ticket creation and assignment has improved dramatically.

I still review decisions from time to time, and I still intervene when a ticket is escalated or when someone disagrees with the objective decision of the tool.

But I rarely need to manually assign routine tickets now.

That was the real goal.

Not to build an AI project.

To remove a recurring operational bottleneck.

Lessons learned

Use AI for judgment, not control flow

The most useful design decision was limiting the LLM’s role.

The LLM classifies ambiguous human text. Python handles repeatable decisions.

That made the system cheaper, faster, more explainable, and easier to tune.

Fairness is a product requirement

A technically correct assignment can still feel unfair if the same person keeps getting picked.

Fairness across time matters, especially for cron-based automations.

Open does not always mean active

A ticket in review is not the same as a ticket in active development.

A ticket waiting for verification is not the same as a ticket that still needs code.

A stale ticket is not the same as a current deadline.

Workflow state matters.

Dry-runs are essential for automation that affects people

If an automation assigns work to humans, you need a way to inspect its decisions before trusting it.

Dry-runs and score breakdowns made this system possible to tune.

Small local models can be useful when the task is narrow

A small local model is not good at everything.

But with a tight prompt, structured output, deterministic guardrails, and a narrow task, it can be good enough to create real operational value.

Closing thoughts

The most interesting part of this project was not the LLM.

The interesting part was turning an informal management process into explicit rules.

Before building this, “assign this ticket fairly” lived in my head. It depended on memory, intuition, interruptions, and context switching.

Now the process is encoded.

It is not perfect. It still needs human oversight. It still needs tuning. But it is consistent, inspectable, and good enough to remove a meaningful amount of daily operational load.

That is the kind of AI automation I find most useful: not replacing judgment entirely, but reducing the repetitive work around it.

A sanitized version of the source code is available on GitHub

This was before AI coding agents were available to help with large migrations like this. Looking back, I sometimes think the project would have been much easier today — or at least I would have had someone very patient to complain to while fixing the 47th deprecated import.

This was not a side project. It was not a clean greenfield application. It was a production system used by real institutes, teachers, students, admins, background workers, scheduled jobs, cache-heavy flows, and tenant-specific functionality.

The upgrade took a little over two and a half months from planning to completion.

The most interesting part was not that the final "requirements.txt" had Django 4.2 in it. The interesting part was that the platform kept running while the foundation underneath it changed piece by piece.

Why we had to do it

The system was already working. There was no product rewrite happening. Users were not asking for a Django upgrade. Nobody opens an LMS and says, “I wish this was running a newer framework.”

The real trigger was compliance.

One of our clients was going through a public-listing-related audit, and as part of that process, their management wanted the legacy environment upgraded. Python 2.7 and Django 1.11 were hard to justify from a compliance and long-term maintenance point of view.

So the goal became clear:

Upgrade the runtime and framework without disrupting production.

The visible product impact would be small. The engineering impact would be huge.

The system I had to upgrade

The production setup was fairly straightforward, but not luxurious.

We had:

• 4 app servers

• 1 common Nginx server

• 1 Celery server

• Redis for cache

• PostgreSQL for the database

• Gunicorn processes managed by Supervisor

• No load balancer

• No PgBouncer

The application was a multi-tenant LMS, so we also had tenant-specific behavior and schema-related concerns to think about.

This matters because a framework upgrade in such a system is not just about making imports pass. It affects web requests, background workers, migrations, cache behavior, authentication flows, admin flows, exams, reports, videos, payments, certificates, live-class integrations, and many smaller pieces that users silently depend on every day.

The ideal outcome was boring production.

No drama. No visible outage. No heroic midnight recovery.

I chose a staircase, not a jump

The final target was Python 3.8 and Django 4.2 LTS.

But I did not try to jump directly from Django 1.11 to Django 4.2.

That would have been too risky. Too many APIs had changed. Too many dependencies could break at once. Too many deprecations would become hard errors together. Debugging failures would become unnecessarily difficult.

So I chose the slower but safer path:

Django 1.11

→ Django 2.0
→ Django 2.1
→ Django 2.2 LTS
→ Django 3.0
→ Django 3.1
→ Django 3.2 LTS
→ Python 3.8
→ Django 4.0
→ Django 4.1
→ Django 4.2 LTS

Before all of this, the first major mountain was Python itself:

Python 2.7 → Python 3.7 → Python 3.8

Every intermediate Django version was deployed to production slowly. There were no big jumps hidden inside local development or staging. The upgrade was done version by version, release note by release note, compatibility issue by compatibility issue.

It was tedious.

It was also the reason it worked.

The first rule: strengthen the test safety net

Before changing Python or Django versions, I wanted confidence that the codebase would tell me when I had broken something.

So the first step was not upgrading Django.

The first step was improving test coverage.

All tests had to pass before I could even think of changing versions. Where coverage was weak, new tests had to be added. I knew that once the runtime changed, failures would come from everywhere: our code, dependencies, Django internals, Python 2/3 differences, serialization, middleware, templates, management commands, and background tasks.

Without tests, this would have been guesswork.

With tests, it became a long but manageable feedback loop.

Along with automated tests, manual testing was also important. Critical LMS flows had to be checked before every major upgrade: login, course access, video playback, exams, payments, reports, admin workflows, Zoom/live-class flows, certificates, and other core functionality.

The test suite did not eliminate risk, but it made risk visible earlier.

That was enough to move forward.

Python 2 to Python 3 was the first real battle

The Python migration came before the Django migration.

I used "2to3", but not as a magic wand. I ran it folder by folder and reviewed the changes. The goal was not just to make the code Python 3 compatible. The goal was to make it compatible with both Python 2.7 and Python 3.7 during the transition.

That distinction was very important.

I created a separate requirements structure for the upgrade. Initially, I cloned the existing requirements and changed only the Python environment. Then I installed Python 3.7 locally, created a separate Python 3 environment, installed the new requirements, ran the local development server, and started running the test suite.

Many tests failed for a long time.

Some failures were expected. Some were surprising. Some came from our code. Some came from third-party packages. Some packages needed upgrades. Some deprecated packages had to be replaced. The requirements folder kept evolving as more incompatibilities surfaced.

But throughout this phase, I followed one rule strictly:

Every code change had to work on both Python 2.7 and Python 3.7.

Backward compatibility was my rollback strategy

I intentionally avoided creating a long-running upgrade branch.

Instead, the upgrade PRs were merged into "master", but only if they remained compatible with the old production runtime.

At first glance, that may sound risky. But for this migration, it was the safer path.

Production was still running Python 2.7. If I had kept all upgrade work in a separate branch for weeks, the eventual merge would have been enormous. It would have been hard to review, hard to test, hard to deploy, and hard to roll back.

By merging small backward-compatible changes into "master", production kept moving safely while the codebase gradually became Python 3 ready.

This made rollback much simpler.

If the Python 3 deployment failed, I did not need to revert a giant branch. I could switch the runtime back to Python 2.7 because the same code still supported it.

That idea shaped the rest of the project.

The upgrade was not just about reaching a new version. It was about making sure every step had an escape route.

Parallel runtimes instead of replacing production in-place

Our app servers used locally installed Python environments and ran the app through Gunicorn, controlled by Supervisor.

For the upgrade, I did not replace the existing runtime in-place.

I created a new Python 3.7 environment and a new Supervisor-controlled Gunicorn process that used the upgraded requirements. The old Python 2.7 Gunicorn process remained available.

Conceptually, it looked like this:

Old stable runtime:
Python 2.7 + old requirements + old Gunicorn

New candidate runtime:
Python 3.7 + new requirements + new Gunicorn

Rollback:
Stop new Gunicorn → Start old Gunicorn

I also set up a GitHub Actions script that could switch between the new and old Gunicorn processes quickly if something went wrong.

This was the heart of the zero-downtime approach.

The new runtime was introduced as a parallel production candidate, not as a destructive replacement.

Later, I repeated the same pattern for Django upgrades as well: separate requirements, separate environment, separate Gunicorn process for the newer version, while keeping the last known stable runtime available for rollback.

Production rollout: one slice at a time

Once the unit tests and manual testing passed locally, I deployed the latest code to staging.

The QA and support teams tested the functionality there. Only after we were reasonably confident did I move toward production.

The first production step was not to upgrade all app servers.

Instead, we set up a new app server and routed requests from only some institutes to that server running the Python 3 setup.

Then we waited.

For two days, we watched for issues.

After that looked stable, we moved to the Celery server. But again, not all at once. We restarted some low-priority Celery worker queues using the new Python 3.7 environment.

Then we waited again.

After another two days without production issues, we moved all Celery workers to Python 3.7.

Only then did we roll out the same setup across all app servers. Even there, the Gunicorn processes were restarted one app server at a time. At any given moment, only one server was restarting.

This meant users did not experience meaningful downtime.

There was a tradeoff: during a rolling deployment, some app servers could be running the old runtime while others were running the new runtime. But because the code changes had been kept backward-compatible, that was acceptable.

That was the whole point of the preparation.

The Redis cache bug I did not see coming

One of the scariest issues appeared after upgrading to Python 3.7 and deploying to staging.

Redis cache data written by Python 2 could not be deserialized properly by Python 3.

This was a major problem because Redis was used heavily across the LMS. It was not just a harmless optimization layer. Cache touched important flows, including OTP login and other performance-sensitive areas.

The lesson was simple:

Cache is production data too.

The issue came from pickle compatibility. Python 2 had stored cached data using pickle protocol 2. Python 3 was trying to read data written by the old runtime and was failing because of serialization differences.

The fix was to make Python 3 read and write cache data in a Python-2-compatible way during the transition.

I set PICKLE_VERSION = 2 in Django settings. To deserialize the old cache data correctly, "latin1" encoding had to be used because Python 2 pickles defaulted to latin1 behavior.

Once this was handled, Python 3 could read the Redis cache data created by Python 2.

This was one of those migration issues that is easy to miss in planning. The code may be compatible. The dependencies may install. The test suite may pass. But production-like data can still surprise you.

After Python came the Django staircase

Once Python 3 was stable in production, I repeated the same workflow for Django.

The Django upgrade was not one upgrade. It was a sequence of production upgrades:

1.11 → 2.0
2.0 → 2.1
2.1 → 2.2
2.2 → 3.0
3.0 → 3.1
3.1 → 3.2
3.2 → 4.0
4.0 → 4.1
4.1 → 4.2

For each version, I carefully read the release notes, removed deprecated usage, upgraded or patched dependencies, ran tests, validated locally, tested on staging, and deployed slowly to production.

This was not glamorous work.

A lot of it was fixing small incompatibilities:

• removed imports

• changed function signatures

• deprecated Django utilities

• old template tags

• outdated package APIs

• middleware changes

• compatibility issues in third-party libraries

But this is exactly why the staircase approach helped.

When something broke, I usually knew which step had caused it.

Python 3.7 to 3.8 before Django 4.0

Before moving to Django 4.0, I upgraded Python from 3.7 to 3.8 because Django 4.0 required Python 3.8 or newer.

Compared to Python 2.7 to Python 3.7, this was much easier. There were no massive language compatibility changes of the same kind.

But I still followed the same process.

Separate environment. Separate Gunicorn process. Tests. Staging. Production rollout. Rollback path.

By that point, the process had become repetitive, and that was a good thing. A boring process is exactly what you want during a risky infrastructure migration.

The hidden work: third-party dependencies

The hardest part of a Django upgrade is often not Django itself.

It is the ecosystem around Django.

A mature production application accumulates dependencies over years. Some remain actively maintained. Some become abandoned. Some work fine until a newer Django version removes an API they silently depended on.

During this upgrade, I had to deal with many dependency-related issues. Some packages could be upgraded cleanly. Some needed replacements. Some needed forks and patches.

A few examples:

• django-pure-pagination

• django-storages

• django-rest-framework-jwt

• django-tenant-schemas

For each package, the question was different:

Is there a newer version?

Does it support this Django version?

Does it still support our use case?

Can we replace it?

Do we need to patch it ourselves?

This dependency work is not very visible from the outside, but it consumes a large part of the real migration effort.

Forking django-tenant-schemas for Django 4.2

One of the most important packages in our system was "django-tenant-schemas".

At the time, it did not support Django 4.2 properly. Since the LMS was multi-tenant, this was not a minor dependency. It was foundational.

The problem appeared while running migrate_schemas.

A migration that changed the primary key field of a model from AutoField to BigAutoField failed with this error:

NotImplementedError: subclasses of BaseDatabaseIntrospection may require a get_sequences() method

Django 4.2 expected the database introspection backend to provide get_sequences(). The tenant schemas backend did not implement it.

So I forked the package and added the missing support.

I also raised a pull request in the original open-source project. Upstream support came months later, after our production system had already been fully upgraded.

This was one of the moments where the upgrade stopped being just release-note work and became framework-internals work. To move forward, I had to understand what Django expected from the database backend and why the tenant schema backend was failing.

Smaller patches that kept the upgrade moving

There were several smaller but necessary patches too.

I forked and patched django-pure-pagination to remove the unsupported ifequal template tag.

I patched django-storages to deal with removed text utilities like "force_text()" and smart_text().

I patched django-rest-framework-jwt to replace removed utilities such as force_text, smart_text, and ugettext"

None of these issues alone would make for a dramatic migration story. But together, they represent the real nature of upgrading a legacy framework application.

It is rarely one big bug.

It is hundreds of small incompatibilities that need patience, testing, and judgment.

Database migrations and tenant safety

Some third-party package upgrades required Django migrations.

Fortunately, most of these migrations were backward-compatible. The project was not mainly a huge application-level schema redesign. The bigger challenge was making sure the upgraded framework, dependencies, and tenant schema tooling behaved correctly together.

The migrate_schemas issue with Django 4.2 was the main reminder that tenant-aware systems need extra care during framework upgrades.

In a single-tenant app, a migration failure is already serious. In a multi-tenant app, migration behavior has another layer of risk because the same operation may need to work correctly across tenant schemas.

Observability and waiting were part of the deployment strategy

During rollout, monitoring mattered a lot.

We had Sentry for runtime exceptions and Uptime Kuma for availability monitoring. These gave us confidence that if something broke, we would know quickly.

But monitoring alone was not the strategy.

Waiting was also part of the strategy.

After routing some institutes to the new Python 3 app server, we waited two days. After moving low-priority Celery queues, we waited again. We expanded the rollout only after each stage looked stable.

That waiting period reduced the blast radius.

It is tempting during an upgrade to rush once things start working. But with production systems, “it worked for five minutes” and “it has survived real usage patterns” are very different levels of confidence.

The full migration timeline

At a high level, the migration looked like this:

Phase 1:
Strengthen tests and prepare separate requirements/environments.

Phase 2:
Make the codebase compatible with both Python 2.7 and Python 3.7.

Phase 3:
Deploy Python 3.7 gradually using parallel Gunicorn processes.

Phase 4:
Move Celery queues gradually.

Phase 5:
Upgrade Django version by version from 1.11 to 3.2.

Phase 6:
Upgrade Python 3.7 to 3.8.

Phase 7:
Upgrade Django 4.0 → 4.1 → 4.2 LTS.

The full effort took a little over two and a half months.

The timeline may sound long, but for a live multi-tenant LMS moving from Python 2.7 and Django 1.11 to Python 3.8 and Django 4.2 LTS, the time was justified.

The goal was not to finish fast.

The goal was to finish safely.

What changed for the business

From a user’s point of view, not much changed visibly.

That was the point.

Students still logged in. Teachers still used the platform. Institutes kept running their courses. Background tasks continued. The system remained available.

Internally, however, the platform had moved away from a legacy runtime and framework stack. The compliance concern was addressed. Future dependency upgrades became easier. Long-term maintenance risk reduced. The foundation became healthier.

It was one of those engineering projects where the value is mostly invisible until you understand the risk it removed.

What I learned

The biggest lesson I learned was that the safest upgrade is the one you can reverse quickly.

A few other lessons stayed with me:

Backward compatibility can be more valuable than clean separation during a migration.

Long-running upgrade branches are dangerous when production must keep moving.

Cache data deserves migration planning.

Celery workers need as much care as web servers.

Framework upgrades are also dependency ecosystem upgrades.

Reading release notes carefully saves production incidents.

And most importantly, zero downtime is not a final deployment trick. It is a property of the entire upgrade strategy.

It starts with how you structure code changes. It depends on how you test. It depends on how you manage environments. It depends on how you roll out Celery. It depends on whether rollback is simple or terrifying.

The best migration is invisible

Looking back, the most satisfying part of the project was not seeing Django 4.2 in the requirements file.

The most satisfying part was that users did not have to care.

The LMS kept running while the underlying Python version changed, the Django framework changed, dependencies changed, Gunicorn processes changed, Celery workers changed, and tenant-related compatibility issues were solved underneath.

That is what made the project meaningful.

A lot of engineering work is like this. If done poorly, everyone notices. If done well, almost nobody does.

And for this upgrade, that was exactly the outcome I wanted.