From what you have said, it seems the machinekey setting in your web.config did not change, and your encrypted user data in your database did not change since the old machinekey works?

If so, it seems like the process worked...  Your encrypted user info was protected while the system was upgraded.  Machinekey follows DATA; connectstrings and db userids and db passwords follow the DATABASE by name.

A new machinekey likely was needed to install/test a new db, and then your old data 'copied' to the new db.  Restoring a db brings the old key.  They could never know or find your old key (w/o access to web.config) so they couldn't change it back...

From Microsoft:

The following steps include references to generating keys for the <machineKey> element. There are a variety of ways to generate key values, and the approaches for doing so are described in the .NET Framework documentation. For more information about configuring view state validation for a network of Web services, see the .NET Framework reference documentation for the <machineKey> element.

1. Generate a validation key. You can use the autogenerate functionality provided by the .NET Framework or you can create the key some other way. Do not use the AutoGenerate option when setting the validationKey attribute.
2. Generate a decryption key. For the decryption key, you can create an explicit value or set decryptionKey to AutoGenerate.
3. Open the Web.config file and set the <machineKey> element. You must specify the validation key, decryption key, and the type of encryption used for validation of data. The following example illustrates the entries you must provide (these example values are not valid; avoid copying these entries into your configuration files): <machineKey validationKey="53ab8bv3ebc93bb826a7b3v37b903a9d5d4a0" decryptionKey="26165b97a9d5d4a0" validation="SHA1"/>

Bob

OK...  That is scary...  Who has/had access to upload or change it?  I would check with whoever did your patches..., maybe change host passwords anyway...

Bob