Developing PHP applications, regardless of the developing system and the deployment one, is usually pretty straight forward.
Since PHP applications are run by an Apache server on all platforms, the choice of which development platform to use and which to deploy on it’s entirely up to the programmer.
Note: Of course, best practices should be followed and the developer should make sure he’s developing on the same version as the deployment server, for each part of his architecture (eg. PHP, Apache, MySQL).
But even while following best practices, developing a Drupal application can prove hard to migrate between Windows and Linux systems. That is because of a function in PHP (serialize) which Drupal makes extensive use of while saving data into the database.
Why is this an issue?
To answer that, we need to get back into the basics of byte ordering for specific types in different operating systems: namely, the byte ordering in integer types.
For serialization, numbers will be represented by their byte representation. The byte representation of a number is basically a series of bytes that add up to the value of the number via a formula.
For a simple example, let’s say we’re storing a 2-byte integer. Since a byte can only hold a value between 0 and 255, the 2-byte integer will be stored as ab where the value is a*256 + b. In this case, we call a the biggest byte and b the smallest byte.
With that in mind, most windows machine use little-endian for saving data. Little meaning that the first address for saving the integer will contain the smallest byte. In essence, on our example above, this means that the number serialized is stored as ba. Smallest byte, b, first, biggest byte, a, second.
So, when developing on a little-endian machine for example, when you will make a database dump to have the data prepared for deployment, all integer values will be serialized as above.
There are server machines though that use big-endian for saving data. Big meaning that the first address for saving the integer will contain the biggest byte. In essence, on our example above, this means that the number serialized is stored as ab. Biggest byte, a, first, smalles byte, b, second.
This of course will manifest into a huge conflict when importing the data into the database. Both from development into deploy environment and vice-versa. The system will interpret integer values (pointers, keys, numbers etc.) as ba instead of ab, and your application will no longer function or, at the very least, not function properly.
In essence, you need to make sure that the deployment machine as well as the development machine have the same byte representation when developing Drupal applications. Otherwise, data migration will not work and all local development needs to be duplicated in the deployed environment.