First of all, why are you adopting Agile?
Remember, Agile is a methodology, and as any methodology, is a means to obtain a result. I may be wrong, but if you're expecting Agile to solve all your problems only for being Agile, you're going to have a bad time. You may be addressing a symptom without dealing with the disease. If you try to go Agile only on your IT side and keeping the same ol' agreements with your stakeholders, you may put yourself in a very complex situation. Or you may not. But be prepared, it might not be easy.
Having that said, your job is to manage expectations. How to estimate big projects? You don't. If you go Agile, you can break down the long term plan into smaller pieces and go Agile over these minor deliverables, where you could provide more certainty and confidence to your stakeholders. You give a high confidence estimate for the first deliverables, and then provide further estimates with less confidence for future deliverables. Needless to say, estimates are NOT dates your team will commit to. They give a high level view of the effort required. As less confidence, as bigger the variation over the given estimates.
These projects are likely to have different views, depending on each stakeholder. In my case, I'm used to use a Kanban board with my IT team and keeping the Gantt to 'speak the same language' of business stakeholders. They're only interested in two things: if we are on track and when are we going to finish... and in this case, the Gantt gives them a bit of comfort (as they're used to it). But again, if you go full Agile, you could provide a similar view using burn down charts... I'd just make sure to have this 'transition' incremental to avoid big impacts (and fear from the unknown).
Disclaimer: I'm an Agile newbie (my project is not even Agile, as you see I'm using Kanban), so take my advice with a grain of salt.