diff --git a/CHANGELOG.md b/CHANGELOG.md
index ef96dd0..2932685 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,9 @@
 # Changes
 
+## 1.7.3 (17 July 2025)
+
+Migration fix: delete TurningPoints w/ project=None (Fix #155)
+
 ## 1.7.2 (17 July 2025)
 
 Various fixes:
diff --git a/issues/migrations/0024_turningpoint_project_alter_not_null.py b/issues/migrations/0024_turningpoint_project_alter_not_null.py
index a14be18..9462a3e 100644
--- a/issues/migrations/0024_turningpoint_project_alter_not_null.py
+++ b/issues/migrations/0024_turningpoint_project_alter_not_null.py
@@ -2,6 +2,18 @@ from django.db import migrations, models
 import django.db.models.deletion
 
 
+def delete_turningpoints_pointing_to_null_project(apps, schema_editor):
+    # In 0023_turningpoint_set_project, we set the project field for TurningPoint to the associated Issue's project.
+    # _However_, at that point in time in our migration-history, Issue's project field was still nullable, and the big
+    # null-project-fk-deleting migration (projects/migrations/0013_delete_objects_pointing_to_null_project.py) is _sure_
+    # not to have run yet (it depends on the present migration). (it wouldn't delete TurningPoints anyway, but it would
+    # delete project-less Issues). Anyway, we just take care of the TurningPoints here (that's ok as per 0013_delete_...
+    # logic, i.e. no-project means no way to access) and it's also possible since they are on the edge of our object
+    # graph.
+    TurningPoint = apps.get_model("issues", "TurningPoint")
+    TurningPoint.objects.filter(project__isnull=True).delete()
+
+
 class Migration(migrations.Migration):
 
     dependencies = [
@@ -10,6 +22,10 @@ class Migration(migrations.Migration):
     ]
 
     operations = [
+        migrations.RunPython(
+            delete_turningpoints_pointing_to_null_project,
+            migrations.RunPython.noop,
+        ),
         migrations.AlterField(
             model_name="turningpoint",
             name="project",