Generally upgrading over 4 versions will result in some warnings and some things broken, as you have observed. First thing is to save the warnings to a file so you can go back through it as often as necessary.
Use the dialog which comes up when you try to run the broken (upgraded) VI. That will take you with one click to places where something is broken. Systematically work through those. Often replacing an obsolete subVI with one from the current palette takes care of most of the problem. You may need to reconnect wires if the connector pane is different. For some replacements you may need to change datatypes on inputs. Examples include arrays to waveform or numerics to enums. As you do this check the functionality of the replacements to see if anything has changed which will affect the performance of your program.
Then work through the warnings list. Verify that the warning does not cause undesired behavior in your program. If it does, then you need to change something. If it does not, make a note to consider modifications to get rid of whatever the warning was about after everything is fully functional.
Although it does not sound like this has occurred in your case, consider whether it would be better to use the old program as a guide to establish a test or performance specification. Use that to write a new program, probably with a better architecture and taking advantage of new features. For example the old program might use lost of sequence structures and local variables, making it difficult to modify or even to understand. The new one might be written using a Producer/Consumer architecture and LVOOP techniques. Rewriting may not take much longer than trying to "fix" the old program and results in a program which takes full advantage of new features and techniques.
I am planning a rewrite this summer or fall in LV 2010 or LV 2011, depending on timing, of a program whose ancestor was written in LV 1.2 in 1988-89. The kind of rewrite I described above has already been done twice on this program.
Lynn
