Freeze-Date Frank™

Meet Freeze-Date Frank. His methodology sounds safe:

Freeze the rules.
Freeze the data.
Stop the changes.

But the business does not stop.

New suppliers are created.
Customers change.
Materials are introduced.
Policies evolve.
Exceptions happen.

And during testing, defects are found.

Those defects are not inconveniences to be handed off to the business after go-live. They are the project’s responsibility to understand, prioritize, fix, retest, and close. The business is not a dumping ground for defects the project could not handle.

The better answer is an agile process built on repeated iterations.

Load earlier.
Test more often.
Review the results.
Fix the defects.
Run it again.

That is how the process improves. That is how the tools become trusted — not because someone declared them ready, but because the testing results proved they were ready.

A freeze should not happen more than 30 days before go-live. Ideally, it should be 14 days or less. By then, the team should already have confidence in the rules, the tools, the reconciliation process, and the cutover plan, because they have been tested repeatedly.

The goal is not to make the project look stable while the business carries the risk. The goal is to resolve defects before go-live and arrive with the smallest, cleanest, most controlled delta possible.

Iterate more. Fix the defects. Freeze later. Protect the business.