Use datapump. (If suitable)
1. No need
Perhaps some data can be migrated before that Downtime?
Make good preparations and time calculations (with priliminary/test partial migration).
1. Do we need to upgrade the source database (either 11.1 or 11.2) to 12c before migration?
This would help if you wanted to drop the database in place as this would allow a standby database to be used which would reduce downtime or a backup and recovery to move the database as is into the Exadata. This does not however allow you the chance to put in some things that could help you on the Exadata such as additional partitioning/adjusting partitioning, Advanced Compression and HCC Compression.
2. Any upgrade activity after migration?
If you upgrade the current environment first then not there would not be additional work. However if you do not then you will need to explore a few options you could have depending on your requirements and desires for your exadata.
3. Which migration method is best suited in our case?
I would suggest some conversations with Oracle and/or a trusted firm that has done a few Exadata implementations to explore your migration options as well as what would be best for your environment as that can depend on a lot of variables that are hard to completely cover in a forum. At a high level I typically have recommended when moving to Exadata that you setup the database to utilize the features of the exadata for best results. The Exadata migrations I have done thus far have been done using Golden Gate where we examine the partitioning of tables, partition the ones that make sense, implement advanced compression and HCC compression where it makes sense, etc. This gives us an environment that fits with the Exadata rather then a drop an existing database in place though that works very well. Doing it with Golden Gate eliminates the migration issues for the database version difference as well as other migration potential issues as it offers the most flexibility, but there is a cost for Golden Gate to be aware of as well so may not work for you and Golden Gate will keep your downtime way down as well and give you opportunity to ensure that the upgrade/implementation will be smooth by giving some real work load testing to be done..
4. Things to be noted before migration activity?
Again I would suggest some conversations with Oracle and/or a trusted firm that has done a few Exadata implementations to explore your migration options as well as what would be best for your environment as that can depend on a lot of variables that are hard to completely cover in a forum. In short here are some items that may help keep in mind exadata is a platform that has some advantages that no other platform can offer, while a drop in place does work and does make improvements, it is nothing compared to the improves that could be if you plan well and implement with the features Exadata has to offer. The use of Real Application Testing Database Replay and flashback database will allow you to implement the features, test then with a real workload and tune it well before production day and allow you to be nearly 100% confident that you have a well running tuned system on the Exadata before going live. The use of Golden Gate allows you to get an in Sync database run many replays of workloads on the Exadata without losing the sync giving you time and ability to test different workload partitioning and compression options. Very nice flexibility.
Hope this helps...