Trunk based development with continuous develivery and microservices are mostly orthogonal concepts. However, for a huge monolith, the delivery cycles which usually require a certain amount of testing will typically last longer, which will work againts the idea of CD.
In theory, having smaller microservices which can be developed and deployed independently can shorten those cycles. In practice, this will only work if you manage it really up to the point where a new release of microservice X has a low risk of breaking the whole system, and you can indeed reduce the necessary amount of integration testing for all other microservices here. For this, X must be strongly decoupled from other parts of the system, and have a certain tolerance against changes of those parts, and those other parts must have a have a certain tolerance against changes of X.
What does that mean for your order of transition? I suggest you try the following:
Identify a part of your system you want to make a (micro-)service of its own. Create the necessary interfaces around it and rework it up to the point to be able to deploy this independently of the rest of the system. This includes a certain backwards and forwards compatibility of the versions of both parts now.
This new service gets a repo of its own and you use trunk based development for it (instead of feature branching).
Repeat this until the remaining core part of the system has become so small that you perceive it as a microservice of its own, and you can switch to trunk-based development for it as well.
Of course, in reality, things will turn out not always to work so straightforward. But the gist of my recommendation here is, try to approach this iteratively and observe where it leads you.