LumasMigration
Already using something else
The API is deliberately close to the classic flat C PDF API. If that is what you are replacing, most of your code compiles against LumasPDF with the call names it already has.
How the compatibility is tested
Not by assertion. The SDK ships a compatibility example suite that run against both engines and are compared — and the other vendor's own example programs are used as the corpus, because an example somebody else wrote is a far harsher test than one we wrote ourselves.
Where behaviour differs we match the other engine on purpose, including in places where we think it is wrong. A migration that needs you to hunt for behavioural differences is not a migration.
What is different, honestly
- Licensing. No activation call and no revocation — how that works.
- Packaging. You buy the one platform and language you build with, not a bundle. There are 17 packages and the price is per package.
- Reporting is a separate add-on with a key of its own, not a bolt-on to the PDF licence.
Coming from something further away
Moving off a Java or .NET-only library, the useful starting point is the example gallery: the same program is written in every binding, so you can read the one in the language you are leaving beside the one you are arriving at.