We already have the ability to the ability to pause and resume Sync on the client device so I guess the secret’s out - we’ve broken our business model ! 
We also only charge 8 100millionths of a penny per sync minute so I’m not sure we are hiding anything - our pricing would give us right away that our business model is not dependent on Sync. I gave a caveats above about pausing sync because we really don’t know because we don’t have tests for this usage of pausing sync but that doesn’t mean it couldn’t work - have you tried it? What problems does it have? I haven’t seen any issues come across my desk - maybe the issues I mentioned above are not a big deal to your usecase
You’re right - we do have an issue on our feedback portal around pausing Sync but it hasn’t gotten too many upvotes, appears to be 7 at this moment opened a year ago, but even then - we already have an API so…
It really sounds like what could help here is an API that automatically converts the data in a local realm to a synced realm. And it is certainly something I’ve thought about, but as with everything in business, its what you decide to focus on that matters. Right now, we have a humungous backlog that we need to pay down. We use Github issues, market trends, field and support team reports, and yes, the feedback portal to fill in our roadmap - right now, I can’t even find a request for something like this “Realm Import API” on the portal so its difficult to gauge what the user interest would be - although maybe if we counted as a vote every time Kurt asked for it we’d have a good showing! 
All joking aside, it’s difficult to see how this feature would beat out other features like a Flutter SDK, the Kotlin MMP SDK, Cascading Deletes, Full-text Search, Hermes Support, Polymorphism & Inheritance - these are all open-source local-only features that have thousands of requests. But this feature has been on my backlog because I do recognize the need for it and I think it makes sense, it’s just difficult to see how this feature beats out these other massive-impact, massive-reach features in the medium-term.
One thing that is unique to the Realm Import API and that is different from all the other features I mentioned above and which you may not have considered is that this feature can actually all be written in user code, generalized, and productized so that it could be reused across many different users without prior knowledge of their schema. Even though we are open source, you could actually design and build this Import API using just our public APIs. This is a community forum, and we are, well, a community - so perhaps we could start a public Github and enlist others to help build a solution. I’m sure even Realm engineers would be happy to stop by to help answer any questions, troubleshoot, and recommend designs. I can even get you started, this Github repo -
https://github.com/realm/realm-sync-samples/tree/master/08-convert-a-local-realm-to-a-synced-realm
Contains code samples of how to do exactly that, convert the data from a local to a synced realm. It works by leveraging Realm’s dynamic API to read the schema. This is an API that we don’t talk about or document very much because our users want a static API - but we use it to power our Schema migration API and we’ve had users in the past who have built other features of it. Of course, Javascript is a dynamic API definition so it doesn’t need a special API but you get the idea.
The code is a bit old, so it’d need to be updated but the design pattern would remain the same; first open the realm and scan the schema of the source realm and instantiate it in the target realm, next copy all objects from the source realm to the target realm by iterating through the objects but keep special attention to links such as a one-to-one or one-to-many, you can see that in the code we key off this type in the code (else if (prop['type'] == "list") then finally do a second pass across the target realm to fill in those links and lists completing the relationships.
I hope this helps -
Best,
Ian