The problem
The production website had speed and accessibility problems. Moving it involved two connected changes: a new hosting environment and a move from MySQL to PostgreSQL.
That made this a system problem. Looking only at the database would miss part of the picture.
Context
A live application depends on more than its code. Database behaviour, server resources, network access, and deployment configuration all affect what visitors experience.
The migration needed to consider compatibility and operations alongside the data itself. The supplied project history confirms the combined move, but does not include benchmark figures.
Options considered
Keeping the database engine while moving hosting would isolate one variable. Changing both could meet the broader infrastructure goal, but would need a wider set of checks.
These are the tradeoffs this kind of migration raises. The detailed decision record is still to be added from the project notes.
Decisions
The work moved the production website and changed the database from MySQL to PostgreSQL. Compatibility, deployment, and operational performance were part of that decision.
One important distinction remains: a better experience after both changes does not prove which change caused it.
Implementation
A useful migration plan separates preparation, transfer, validation, and cutover. For a Django application, database settings are one small part of that work.
# Educational example, not production configuration.
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "application",
# Load credentials from private environment configuration.
}
}The application also needs checks for relationships, constraints, important workflows, and deployment settings. Exact commands and the project-specific cutover sequence are editable details to add.
Challenges
Changing multiple parts of a live system makes diagnosis harder. Data compatibility and deployment behaviour need separate checks, even when they belong to one migration.
The available information does not establish a zero-downtime cutover, a measured speed increase, or a specific query failure. Those claims are deliberately absent.
Outcomes
The combined database and hosting changes resolved the speed and accessibility problems previously experienced.
That is the supported outcome. No performance percentage is available, and the database move alone should not receive credit for the improvement.
Lessons learned
Describe a system change at the level the evidence supports. When several things move together, keep the result separate from assumptions about its cause.
For a future migration, document a clear baseline, a validation list, and a rollback plan before cutover. These are planning recommendations, rather than claims about an undocumented incident.