Application workloads that migrate to the cloud often need some work before the move, but IT usually opts to get the workloads to the cloud as expeditiously as possible, which means the workloads often go to the cloud as is.
If you don’t modify or refactor the application or data, you will probably not take advantage of some cloud-native features that could really improve your ROI. However, when you do modify the application, you must consider portability trade-offs.
Can you move your application workload to the public cloud without any modification? Perhaps, but only if the workload in question passes these tests. All three answers must be yes.
Test 1: Is the data decoupled from the application?
If the data and application are tightly coupled, you cannot run the data and the application in separate workspaces. They should be separated before they're moved to a public cloud, where distribution of the workloads brings performance and reliability advantages.
Test 2: Is the application unbound to an older security framework?
Sometimes, hard-coding security into the application is not an issue unto itself -- unless it’s an outdated model that will open the application up to attacks. That's why the security approach should be decoupled from the application, but still be interdependent. This approach will provide the flexibility needed to proactively update security.
Test 3: Is the application designed well, with multiplatform deployment in mind?
The problem with migrating application workloads to the cloud: If they are poorly designed, they run poorly anywhere -- including the cloud. Applications that are well designed run well anywhere. If they are not well designed, you need to redesign and recode them before moving them to a public cloud.
Of course there are other issues to consider in assessing cloud migration needs, but these three are the first questions to ask before you sort those that can move as is to the cloud and those that need to be modified first (and why).