I have recently been involved in a similar assessment for a client – not specifically concerning just Perl but a number of different internal applications.   A capsule summary of our findings would be this:

(1)   The Win32 API upon which all software of course depends remains largely unchanged.   Therefore, applications and DLLs by and large continue to execute as expected.   A smörgåsbord of non-API libraries have experienced the usual set of changes, which will or will not affect you according to exactly how your particular applications are link-edited.   In the case of Perl, for example, some CPAN libraries that are “wrappers” for other libraries may require rebuilding, and the CPANTS test-outcomes tables should be consulted well in advance.

-----

(2)   The most significant change of Win7 is, of course, the security-infrastructure management, which has continued to become more visible and intrusive.   Digitally-signed installers ... and therefore, the use of installers at the exclusion of every other installation option ... now receive an almost fanatical degree of attention.   I expect that Strawberry Perl will by its nature have difficulty with this, and that Active State Perl will continue to become more expensive.   ... :-) ...   And actually, that wasn’t an attempt at humor.

Windows 7 reflects the realization that most “rogue” software that seriously causes harm arrives on a computer by being installed there.   Applications are intentionally being made very difficult to install by any means other than the use of an installer, and installers are made virtually impossible to use at all unless they are digitally signed.   While this makes perfect sense for an application, and is already in common use e.g. on smart phones and tablets, it does present problems for a complex language-system such as Perl, as it also does for many in-house applications not related to Perl.   Windows (finally) pays very close attention to where a DLL or an executable may be located.   It has the power to restrict overrides to the library search-path.   It can require signed-code anywhere.

In summary, I think that a proper answer to your question will be more complex than simply determining whether or not the Strawberry Perl core runs on Windows-7.   (It does.)   What will be of concern is whether the entire set of CPAN libraries that your systems directly or indirectly use can, on a case-wise basis, successfully build and install themselves on all of your company’s Windows-7 targets.   To that end, you need to find a way to work closely with the IT teams now, presenting the Perl-based target applications (not “Perl itself”) as the systems that your business must legitimately be able to run.   You will get buy-in by pointing out, not only that Perl is not the exception nor exceptional, but that it is the means to an end.

-----

(3)   More-or-less as a footnote ... the 32/64-bit issue applies in the usual way.   A representative target build-system must be set aside, and Strawberry (with all of your CPAN requirements) must be built upon it to assure compatibility.   Once a stable code-base of the entire application is assured, a conventional installer can be used for simplified deployment, and if this be so, a Windows-7 aware version of the installer de jour should be used.   In other words, you might wish to build Strawberry, and do all of the installations of CPAN material, then “snapshot” the whole thing for deployment purposes using a different installer ... one which is purposed to install the application(s) on a target computer.   Your company may well wish to apply their own digital signature to that installer.   The same procedure may be advisable in the case of their existing “purely home-grown” internal applications, as well.