I was on one of those teams for my company, and we had simulations of various software (especially ours) to see what would break in such a scenario. When we started in earnest in 1998, it was pretty bad. It wasn't just "99 turned to 00" but how even small sub routines would start strange paths.

For example, "RNG," the random number generators, were often seeded by a date string as a cheat. If these failed, the random numbers would all be rather predictable. All at once. This affected the primitive cryptography we had in various transfers. We had to redo how that was done.

It would affect time zones. Jan 1 1900 was a Monday, but Jan 1 2000 was a Saturday. Depending on the underlying library, this could fuck up how leap year was calculated, and Feb 29 may or may not happen, so a daylight savings time call would be off by a day.

But the big one was 98 < 99, but 99 > 00 which was the core of the Y2k issues. But you know who had already fixed a lot of that? Banks. Specifically dealing with mortgages. They knew by 1970 this would be a problem with 30 year mortgages. So by 1998, there was already a lot of pre-work and some documentation by those that had worked on our backend systems.

No stone went unturned. If it could be tested, it was, and we had a shit ton of online connections in the days of dialup, so we had to test how our equipment would working it knew in was 2000, but what it connects to thought it was 1900. But believe you me, it was scary because we were an international company and knew just because the US was being vigilant, that didn't mean Japan was. Or Australia. Or China. So, when it was New Years there first, we were bracing for "you have 16 hours to fix the shit Sydney is running into before it hits the US." That was a nervous Friday, let me tell you.

Luckily, it wasn't nearly anything. There were small things, like dates on security video cameras, but that was more cosmetic.