I'll take it from a couple of different perspectives to provide some context.
As I mentioned earlier, the system we're replacing is over 30 years old, so the complications with that system in looking at trying to run things in parallel—making changes to that system and keeping things in sync—were conversations that happened early on in the process. I was not part of those conversations, but my understanding is that it was deemed to be not feasible because of the complexities of the aging system and the technologies that were there.
The other piece of it is that the solution is being rolled out in a series of different releases. This is probably release five, six or seven of this solution. It's not that we haven't thought through how to roll it out more thoughtfully. We started back with release zero. We had a release of what we've affectionately called R2 internally at the CBSA. We're moving to R3. There have been ongoing releases throughout the life cycle of the program.
In terms of the 16-day blackout period, I think what's important to remember here is that we are actually migrating 6.7 billion records of historical transactions that need to be there for the CBSA to do any sort of reconciliation and have any sort of history of those transactions as they move forward. That is not a small volume. It's a very big volume, and that is partly what requires the amount of time for the blackout period.
The other component of that is that we have left ourselves some time in there to make sure we have some contingency, so that we have time within that blackout period if something unforeseen should happen. In my years of doing this, I have seen all kinds of unforeseen things happen. It can be anything from the city taking the power down to a fire in the building. We can't plan for the things we don't know, which is why we've also left ourselves some contingency in that time frame.