As you only change the deployment structure and not the instance itself (CQ/CRX doesn't matter if it runs within WAS or CQSE), you could try the following approach:
* Create a new instance of CQ 5.3/CRX 2.2 with CQSE
* Shutdown this instance
* Copy over the launchpad and the repository folders recursively from your WAS instance
* make necessary changes to the start script & startup this instance
* If you have used proprietary APIs of WAS, it probably won't work
* If you used WAS infrastructure, it won't work. CQSE is only a servlet engine.
I have tried this, but sling does not even start. CRX starts fine in anycase, but if we do much of anything to luanchpad, sling will not start. We get a class not found for org.apachje.sling.launchpad.api.LaunchpadConentProvider - we tried replacing the org.apache.sling.launchpad.core.jar from our copy of the launchpad with one from a clean CQ 5.3 install, but then we get a raft of bundle errors and then java.lang.IllegalStateException: zip file closed.
I know when we upgraded our WAS install to CRX 2.2 we replaced not only the CRX war but the CQ Launchpad one as well, and I think this has made it incompatible with a simple CQSE 5.3 CRX 2.2 build where that launchpad war file is never updated. I think we're close.
Now I think I understand the root of the problem. In our WAS environemtn we followed the Upgrade to CRX 2.2 documentation and used the associated file, which contains a new crx and cq launchpad war file. I nthe new CQSE build, when I go to upgrade to CRX 2.2, I have to follow the upgrading CRX in CQ document, which has only the one new war (replacing two wars). One would think that then upgradeing the cq launchpad war ( the / module) would work around this, but it appears not. I am goi ngto work through this again to see how it goes and what errors I get.
On the fresh cq instance make sure to install the latest crx hotfix that you have installed in websphere. Because all those jar file exists under cq_home/crx-quickstart/server/runtime/0/_crx/...