I'm doing a inplace upgrade form 5.6.1 to aem 6.2, actually to 6.4 but its recommended to take a hop.
Following this Upgrading to AEM 6.2 for same.
On Dev server, repo size is 280GB.
Performed consistency and traversal check which took around 3 days.
Later ran crx2oak command.
java -Xmx32G -XX:MaxPermSize=4096m -jar cq5-author-p4502.jar -v -x crx2oak -xargs -- -o migrate
Set log level to 'info' (Is this correct or what can be for such a huge repo?).
Oak migration has finished in around 7-8 hours and reindexing is still happening from past 6 days.
It looked unusual to me.
Please help if the approach i'm following is correct and is usual.
Any specific preupgrade steps needs to be performed before executing the oak migration command.?
Using latest version of crx2oak migration tool helps.?
any key include & exclude paths to be given while running the crx2oak command
I'm worried, Coz the production is around 480GB and cannot wait for days to finish the inplace upgrade
Please share a guide or any kind of SOP/document if someone has done same practice earlier.
I hope you are using AEM 6.2 jar to run crx2oak.
java -Xmx32G -XX:MaxPermSize=4096m -jar cq5-author-p4502.jar -v -x crx2oak -xargs -- -o migrate.
Use the crx2oak bundled with AEM 6.2
Also, can you check your index logs . Are the logs looping? It might be possible that re-indexing is failing. Can you upload your logs for review.
Best would be to open a daycare ticket so that we can take a closer look into your system.
Yes the jar used to run the crx2oak was of AEM 6.2.
The indexing got finished today after 7 days. But we cannot wait for days to finish the in place upgrade on other servers. Please suggest any way to migrate 480 GB repository in a short span of time.
You have a large repository and hence it's expected that a migration/upgrade will take significant time. You can try to clean your CQ 5.6.x repository manually to reduce the total number of nodes to migrate over to AEM 6.x.
1. Stop all replication agents, workflows and launchers.
2. Make sure that you stop, terminate all workflows instances.
3. Using content explorer (or CRXDE) create /tmp/todelete folder
4. Move the following folders to /tmp/todelete
After you move workflow instances node, you must immediately recreate an empty /etc/workflow/instances folder with exactly same properties)
5. Review /etc/packages folder and check if there any big in file size *.zip archives that you do not necessarily need to keep.
6. Stop and start CQ
7. Begin deleting recursively /tmp/todelete.
8. Run tar optimization.
9. Run datastore GC.
10. Run a consistency check. It is a good practice to re-build indexes along with a consistency check:
I'm assumed that there would be a chance of failure if you're doing it straight to aem 6.4 for various reasons. Also repository needs to go through crx2oak migration.
Can you help me understand how you achieved straight from 5.6.1 straight to AEM 6.5 (Upgrade doc or Process steps, pre-upgrade, U-grade & post-upgrade). I will try to relate it to my scenario and check for possibilities.
There is no need for intermediate upgrade to 6.2, you should be able to directly able to upgrade from 5.6.1 to 6.4. The hop is only necessary when moving from any version older than 5.6.
Detailed upgrade steps at 
Follow what berliant outlined.
Think of it as 3 main operations that need to be done in order:
1) Unpack the 6.4 or 6.5 jar file over the CQ 5.6 instance. So place that alongside the cq5.6 jar and unpack.
java -Xmx4096m -jar cq-quickstart-6.4.0.jar -unpack
2) Perform repository / segmentstore migration -- this is where we make the jump from crx2 used in cq5.6 to oak-segment-tar used in aem 6.4 or 6.5.
java -Xmx4096m -jar cq-quickstart-6.4.0.jar -v -x crx2oak -xargs -- --load-profile segment-fds
3) Perform the actual upgrade. Do this by starting the 6.4/6.5 quickstart jar without (important) any scripts.
java -server -Xmx4096m -XX:MaxPermSize=256M -Djava.awt.headless=true -Dsling.run.modes=author,crx3,crx3tar -jar cq-quickstart-6.4.0.jar start -c crx-quickstart -i launchpad -p 4502 -Dsling.properties=conf/sling.properties
Monitor the upgrade.log and error.log
In upgrade.log look for : c.a.g.c.e.MigrationRunner: migration COMPLETED