Hi all,
Routinely, and more and more frequently, groups that are managing OpenMRS distributions are approaching us with a simple question that goes along the lines of:
I need an integrated system and I would like to follow a similar approach as what Ozone does
The first thing to know is that, while it is crystallising around its first stable version, Ozone is being designed with inheritance and overridability in mind (see for instance this comment of mine on Slack).
Second, I will answer this question for existing OpenMRS distributions out there, and not for existing integrated systems out there. This is because the question is in essence to know how to turn a mono-system OpenMRS distribution into an Ozone-like integrated system.
The base principle is to depend (with Maven) on an Ozone release and then shape it through additions/subtractions/overrides to achieve your goals. However Ozone, whether FOSS or Pro, will pull the reference packages of all its components, in particular its EMR component which by default is the latest release of Ref App 3.x.
Explicitly depending on Ozone will therefore bring you the Ref App as it was released. Therefore transitioning to Ozone HIS will require groups to 
analyse carefully the delta between their own OpenMRS distribution and the latest release of the Ref App 3.x. This is in order to understand all the additions/subtractions/overrides steps needed to go from the Ref App 3.x to their target OpenMRS distribution when introducing the Ozone dependency.
There is some technical analysis leg work 
, but then the benefits are around the corner. Most notably the fact that your own distribution will “just” inherit (depend on) an upstream core product (firstly Ozone and then transitively the Ref App 3.x among other Ozone standard components) - and this has huge long term maintenance benefits. Namely you won’t have to maintain an entire distribution anymore, you will only have to maintain the differences between your distribution and reference products that you can keep upgrading 
(“upgradability” is increasingly becoming a hot requirement out there).
The closest that we can (publicly) showcase of this being done practically is with Oz Kh (the Ozone Distribution for Cambodia) here. This small innocuous Maven dependency statement implies that Oz Kh starts off Ozone FOSS, and then configures it to be what it should be.
However I suggest that you reach out here or on Slack if you are attempting the same because currently things are in motion and the way Ozone is packaged and deployed will change (soon) ahead of its first beta release.