Lightweight migrations are intended to be accumulative. This is especially true if you don't use formal versioning.
I always tell clients that lightweight migration is intended largely for development purposes. You're counting on a piece of software being able to puzzle out the changes between versions. The smaller and simpler the changes the better the software can manage. At some point the change become to complex for the software to handle.
Without formal versioning you can in principle you skip a "version" as long as the software can figure out the changes. In practice, the migration software is easily confused and will break if you make any substantial changes.
For deployment, you should always plan on using "full-weight" versioned migration. This is especially true if you envision many updates. Do you expect the software to be able to handle a migration from version 1 to version 5 or higher as well as any between any two or more versions in between?
Remember as well that the previous model file has to be present for any migration to work. If you intend to skip versions, formal or otherwise, you have to retain all the model files for all the previous versions you want to migrate. If your update for version 5 does not provide or retain the model for version 3, you can't perform any migration of the existing store. In practice, this means shipping each version with all previous versions' model files. It's usually easier and safer to upgrade in series and end users are used to doing so.
It's really impossible to tell what your actual problem is in this case without looking at the models in detail. It could be a simple as the migration being to complex for the lightweight migration software to handle. The software can't understand how version 5 maps onto version 3.