There is a huge difference in number of events coming in after migrating to Graph

Yes. A higher notification volume after moving from EWS to Microsoft Graph can be expected for a few reasons shown in the documentation.

1. EWS notifications are already known to be noisy In EWS, a single user action can generate multiple notifications. For example, a folder move can create events for the folder, the old parent, and the new parent. Calendar scenarios are especially noisy, and a single meeting request can create both create and modify notifications. The recommended EWS pattern is to add a short delay before syncing so the operation completes and related notifications can be handled together.
2. Graph change notifications are a different model In Microsoft Graph, subscriptions are for resource changes such as created, updated, and deleted on Outlook event, message, and contact resources. These are not a 1:1 mapping to EWS CreatedEvent, ModifiedEvent, and MovedEvent. Comparing raw counts between EWS and Graph is therefore not an apples-to-apples comparison.
3. Lifecycle notifications add extra traffic in Graph Microsoft Graph can send lifecycle notifications to the lifecycleNotificationUrl. These include:
   • reauthorizationRequired
   • subscriptionRemoved
   • missed
   These are separate from normal resource change notifications, so they increase the total number of POSTs received by the endpoint.
4. Large numbers of lifecycle notifications are not normal to ignore Lifecycle notifications exist to signal action is required. If they are frequent, the app should handle them. In particular, missed notifications mean some change notifications were not delivered, for example because of throttling. The documented response is:
   1. Return 202 Accepted
   2. Validate authenticity
   3. Perform a full resync of the resource, for example by using delta query
5. Possible reason for the perceived increase Part of the increase may be that Graph is counting both:
   • normal change notifications
   • lifecycle notifications
   EWS documentation also states that notification-based synchronization can lose notifications if the mailbox server managing the subscription becomes unavailable, and mitigation is required. Graph explicitly surfaces lifecycle events such as missed, which makes delivery issues more visible instead of silent.
6. Practical handling guidance
   • Separate normal change notifications from lifecycle notifications in processing and metrics.
   • Do not treat lifecycle notifications as business data changes.
   • Add debounce or short-delay processing for calendar changes, because related updates can occur close together.
   • When missed notifications arrive, resync instead of trying to infer the missing individual changes.

If the workload is Outlook calendar synchronization, the key takeaway is that both systems can produce multiple notifications for one user action, but Graph also introduces lifecycle notifications, which can materially increase the total event count seen by the application.

References:

• Notification subscriptions, mailbox events, and EWS in Exchange
• Mailbox synchronization and EWS in Exchange
• Reduce missing subscriptions and change notifications
• Microsoft Graph API change notifications
• Change notifications for Outlook resources in Microsoft Graph
• Getting immediate multiple update meeting event after create event - Microsoft Q&A