One difficult aspect of migration is understanding the differences between the social features and the request methods or endpoints of each container. This problem is compounded when social request logic is deeply ingrained in the core application code base.

Decoupling social logic from the main visualization and controller code is one method for easing the pain of migration. You can start this process by mapping the social endpoints, or social data request code, to variables and creating separate function logic for parsing container-specific social structures. At the end of this process, you will have functionality that resembles a container’s API, where functions can be defined for obtaining and parsing connections, activities, or any number of other social features. Using logic like this allows you to include simple function calls in your mainstream code, meaning that if you need to make changes to that functionality, you have to update only those modularized functions.