Steph40

As we get closer to our first release, we'll be discussing how to update your custom applications to be compatible with IPS v5. We know this can seem like a daunting task, especially since not all changes will be immediately obvious, so we'll be walking through this step by step.
 
Updating Source Classes
Classnames should no longer start with an underscore. All our source classes are now strictly typed, so any of your classes that extend pretty much anything (Content Items, Nodes, Active Record) will need to be updated with the correct method signatures and property types. Almost all Content interfaces have been converted to traits (e.g. \IPS\Content\Pinnable, \IPS\Content\Lockable). Your content classes should have use statements instead of implements, and if you are overloading any trait methods, verify that it is properly declared.
The following interfaces have not been moved to traits:
\IPS\Content\Embeddable
\IPS\Content\Filter
\IPS\Node\Permissions \IPS\Content\Searchable has been removed entirely and replaced with a SearchContent extension. Recommended: We no longer use FQN in our code. This is not required for v5 compatibility, but a recommendation for best practice.

A few examples of the changes to the code base, showing strictly typed function signatures and using traits versus interfaces
Updating Extensions
All extensions now have an abstract class that should be extended. Most of these can be found under \IPS\Extensions. The abstract class is typically the same name as the extension type (e.g. EditorLocations extend EditorLocationsAbstract). Verify that your extensions use the correct abstract class and that all your method signatures and properties are declared correctly. Remove deprecated extensions. See this blog entry for a complete list. Convert your CreateMenu extensions to a UserMenu extension. Convert your MemberSync extensions to a Listener.  
Replacing Code Hooks
The following is a general list of the most common types of code hooks. Obviously, we cannot predict, nor support, all possibilities, but we have tried to cover the basics here.
Hooks on content classes should be replaced with Listeners or UI Extensions. Hooks on the Dispatcher (e.g. for loading JS/CSS) should be converted to Loader Extensions. Hooks on commerce items should be replaced with Listeners. Hooks that add functionality (e.g. Commerce gateways, Login handlers) should be moved to the appropriate extensions.  
Replacing Theme Hooks
As with code hooks, below is a list of common uses for theme hooks.
Theme hooks that add to the user dropdown menu should be moved to a UserMenu extension. Theme hooks that add classes or attributes should be moved to UI Extensions. Theme hooks that insert HTML should be moved to template hooks.  
Please let us know in the comments if there is anything that we may have missed, or if something is unclear. We would like to make this transition as smooth as possible.