restructuring tables and model relationships in order to use STI

Hey James! I'm going back to the garage app and want to implement some of the things I learned from you over the last couple of weeks. As a first step, I'm restructuring the models and databases. Planning to use STI for Users (with Customers and Employees inheriting from User) and for Repairs, with Invoices and Estimates inheriting from Repairs.
This migration name doesn't convey what the update was or the reason why it's being done. It should have one or both of these ingredients, so people can read through migration file names and find the one they're looking for easily. Imagine someone looking through old code saying to themselves "I wonder where that note column went to, and why?". UpdateAppointmentTable *could* be it, but so could a lot of other vaguely named migrations involving this table.