Directions USA 2013 | Real World Upgrades

Real world upgrades

For those of you who don’t know him, Tom Wickstrom is THE upgrade specialist. He has done over 600 upgrades since 1999.

I’ve personally worked with Tom on more than 30 projects.

Estimating

Tom recommends quoting upgrades fixed price. However this requires to compile a list up front with objects that cannot be merged but need redesigned.

For comparing reports Tom has a tool that removes RDLC code to be able to see real changes to the report.

Another thing that needs to be considered are changes that cannot be brought forward or features that are now available in the standard solutions.

If programming is needed for redesign this needs to be included in the price, either fixed price or on hourly bases.

Customers also have to reconsider their hardware. Is the hardware still adequate for the new version.

Another advice is to add enough time for training and emotional support since end users will have to get used to new ways of working.

Expectations

Look at your customer organisation and try to estimate if there will be resistance. Resistance is a big risk in the project.

Make sure to schedule time for testing.

The customers license needs to be refreshed and tested. It happens sometimes that refreshed licenses are not good.

If it is necessary to replace hardware make sure it is there in time and test on this hardware.

Test with end user access rights, not with super. Make sure the real endusers do testing.

Make sure no one is on vacation or unavailable when you need them for the project.

During the final cutover the database will be down. This takes time and need to be calculated.

Testing

Make sure to have test script.

If you cannot test on the golive machine, make sure to test on hardware that is equivalent.

Track the test results and maintain software incidents. (SIR).

Just because a document got posted does not mean the posted document is ok. Test, test test and look at the results.

Testing is the most important part of an upgrade.

If something went wrong, why did it go wrong. Is it programming or setup? Or is the user using the system wrong. Or is the new version behaving differently and is the result good but no what the customer expects.

Go Live

Before go-live use a testing complete sheet where the customer signs that the upgrade has been tested and no more errors exist.

After this is signed new errors are no longer within fixed price. This is not to make more money but to encourage people to test.

Everyone within the team needs to be available.

Be sure to be onsite for the first 1-3 days. Help endusers and do emotional support.

Recipes for disasters

By far the biggest risk is programming in live databases after the upgrade has been started.

Little less complicated is programming in the testing database, but that needs to be synchronised with the upgrade objects.

Compressed item ledger entries in older versions cannot be upgraded, the costing will be messed off.

This feature does not exist anymore.

If someone of the team is unavailable and needed for something.