Søren,
As you mention, this is a challenge for many types of applications that have dependencies on other systems and components. The scenario you describe is what I refer to as a "breaking change". Something where the changes you are introducing may break existing functionality.
Since you say that you don't have control of the transport timing, you may need to take extra steps to ensure things don't break.
In these cases, one option is to create new methods so that rather than modifying the existing fetch for example, you create a new fetch instead that will exist in parallel with the current one. It can of course start with a copy of the existing fetch code under a new name.
This will allow for the transport to be propagated to the next environment without impacting the operation of the existing application. Once you have confirmed the transport was applied correctly to the new environment, you can then schedule the update to the application / java knowing the transport is already in place.
It does involve some extra work but is something to consider if you really can't control the transport timing during a production deploy / rollout.
--Bill