The “hard way” part should still work properly (we still have some internal missions built this way). We do not plan to remove support for this, and migrating a mission to airsdk-cli should not be mandatory.
What are the errors you are encountering with your mission ? If your mission fails to load, could you check the “status” of the mission from the drone webserver ?
If you still want to migrate your mission, we do not yet have a real “migration guide”, but here are a few pointers:
airsdk-cli requires the source code hierarchy to match the module types/names (i.e. sources for a service named some_service must reside in service/some_service/)
Since you already have an atom.mk file declaring all of your modules, you can split it into individual files (one module per atom.mk, located in the module source directory) and use the lang: custom feature of airsdk-cli to reuse all of the build instructions you’ve already written
Messages don’t support the lang: custom, and thus will require a few changes. They must reside into the msghub/ directory, and all the build part related to them (lines 40-91 and 117-137 in case of the hello mission) will be automatically generated (cf lines 18-24 of the mission.yaml file)
The metadata: part of the mission.yaml file is the same as the old mission.json.
Most of the product/ directory will be automatically generated, except for the product/[...]/skel/ directory, which is replaced by the assets/ directory.