the first rule for migrating to systemd

At this point, in 2015, it's most likely that someone has already done it.

systemd has been around for some years. And there has been a whole cottage industry of people writing unit files and publishing them. GitHub, in particular, seems to attract repositories of collections of service units.

Indeed simply searching the WWW for autossh.service (as a phrase) turns up:

• Phillipp Klaus doing this in 2013
• Thomaz Fritz doing this in 2014
• unknown people doing this in 2013

a template unit

That said, as I've pointed out in several places on StackExchange alone, this sort of migration is not a mechanistic process, and sometimes just robotically translating from whatever one has to a unit file is doing things wrongly, or at least poorly. In this case, autossh is positively panting to be handled with a template unit, that it is instantiated into actual service units, parameterized by the target name. So as /etc/systemd/system/autossh@.service, have:

[Unit]
Description=AutoSSH service for a reverse tunnel from %i 
After=network.target

[Service]
User=autossh
EnvironmentFile=/etc/%p/%i.conf
ExecStart=/usr/bin/autossh -M 0 -q -N $SSH_USER@%i $SSH_OPTIONS

[Install]
WantedBy=multi-user.target

Create a file named /etc/autossh/other_server.example.conf with, minimally:

SSH_USER=joe

All of the usual controls then apply:

• systemctl enable autossh@other_server.example — Enable an instance to be automatically started at bootstrap.
• systemctl start autossh@other_server.example — Manually start that instance immediately.
• systemctl status autossh@other_server.example — See its status.

And yes, the first rule even applies to this. Searching, one can find that I was beaten to this, by just under a fortnight, by Greg Freemyer at OpenSUSE.

Since 15.04, init on Ubuntu is systemd. It is possible to use Upstart, but the default is systemd. For example, /sbin/init will be a link to /lib/systemd/systemd. /sbin/{shutdown,reboot,telinit,halt,runlevel,poweroff} are links to /sbin/systemctl. Even in 16.04, Upstart was used as a session init, so you might see Upstart as the parent process or an ancestor process in your graphical login (though it seems to have changed in 16.10).

The other processes you see are systemd components; they're developed and distributed along with systemd but many are not essential to running systemd as init. Many components can be replaced or disabled. To quote the systemd homepage:

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. ... Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.

And this blog post from one of the creators of systemd (Lennart Poettering):

29. Myth: systemd doesn't allow your to replace its components.

    Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.