Upgrade Perl from 5.6 to 5.24

We are currently using 5.6 version of Perl in our organisation, along with MySQL and Apache, but now the client wants to upgrade Perl to v5.24.

What are all the major changes and key points that must be kept in mind before starting an upgrade?

I surfed a lot, but I didn't find anything interesting for moving from 5.6 to 5.24.

Is it advisable to move from this much lower version to advanced level?

If you go to CPAN for the chosen version of you are moving to (in your case 5.24.0 Perl 5.24.0), and look down in the Documentation section there are bunch of perlXXXdelta links. These files describe the changes between revisions and more importantly they detail the incompatible changes. You can also find these online.

Version 5.24.0 details its changes in pod/perldelta.pod.

There are number of notable differences:

• 5.8 changed binary format, so you have to recompile .XS modules.
• 5.8 moved to PerlIO for core I/O operations.
• 5.8 changed how wide-character strings work. This changed the role of use utf8.
• 5.10 made unpack() and mkdir() default to using $_
• 5.10 retired $* and $#
• 5.10 made it that $AUTOLOAD, printf and sprintf are now taintable
• 5.12 reordered @INC to allow core modules to be upgraded
• 5.12 blesses file handles into IO::File
• 5.12 suidperl was dropped
• 5.12 deprecated UNIVERSAL->import()
• 5.14 was another binary incompability change
• 5.14 change the referencing of glob handles.
• 5.14 local($_) strips all magic from $_
• 5.14 := became a syntax error
• 5.18 hash ordering is even less predictable than before
• 5.18 \s now matches \cK (the vertical tab)
• 5.18 readline() with $/ = \N now reads N characters, not N bytes
• 5.20 do SUBROUTINE(LIST) became a syntax error
• 5.20 for certain data structures, Data::Dumper output has changed
• 5.24 Lexical $_ was removed
• 5.24 chdir('') no longer changes directory to home

I would suggest you go over these files in detail (it will keep you busy given your huge version bump!). This is especially the case if you have a good knowledge of your code base and the Perl features it utilizes. This should at least give you a sense of the potential pitfalls you may face in migrating to later versions.

I would also add that Borodin's answer is worth a read, as it details a very good approach to dealing with the upgrade. I agree wholeheartedly with his recommendations, especially unit testing - it is a sure way to increase confidence in the success of the migration. If you have no unit tests, then this would be an excellent time to introduce them, as well as being able to justify the time spent creating them for your organisation.