The native mechanism for this system is the service bundle.
One can, however, import systemd unit files.
The system-control convert-systemd-units command takes systemd unit files and converts them to a service bundle directory.
This conversion program allows software packagers to quickly construct a service bundle if they already have systemd unit files for a service.
(It also allows system administrators to do this in the case that software packagers have not.)
Five kinds of unit can be converted:
a target unit with no associated service, that simply aggregates other services and targets, or that operates as a milestone;
a simple service unit;
a templatized service unit;
a socket unit that invokes a simple service unit of the same name;
a socket unit that invokes a templatized service unit of the same name.
There are a few restrictions (summarized here, for details, see the convert-systemd-units manual):
The service must be a forking, oneshot, dbus, or simple service; not a notify service.
The socket must be a TCP, UDP, local-domain stream, local-domain datagram, local-domain sequential-packet, FIFO, or netlink datagram socket. Other socket types are not convertible, although there's nothing in principle stopping UCSPI tools and conventions for them from being invented and used.
Some esoteric options are not convertible. Nor are some Linux-kernel-only options.
These cover a large number of unit files, in practice.
convert-systemd-units breaks down the unit files and builds run, start, and service scripts that use the various utility programs to set up a service's run-time environment in the way specified by the unit files.
(This is only a subset of what a run script can actually do.)
A User= directive becomes a setuidgid command, for example.
Import can operate in either "ideal" mode or "quirks" mode.
Quirks mode deals with several quirks of systemd and is the mode to use when taking existing unit files supplied with other packages.
See the convert-systemd-units manual for details.