Mapping cron onto OnCalendar
systemd timers express schedules as OnCalendar=DayOfWeek Year-Month-Day Hour:Minute:Second, with * wildcards, comma lists, .. ranges and / steps. So cron's 30 2 * * 1-5 becomes Mon..Fri *-*-* 02:30:00, and */15 * * * * becomes *-*-* *:00/15:00. The converter handles numeric fields, lists, ranges and step values (the constructions that cover practically every real crontab) and anything exotic gets an explicit error rather than a silently wrong schedule. Always confirm with systemd-analyze calendar, which prints the actual next elapse times; the command is included in the generated output.
What you gain over cron
The generated timer includes the two directives that justify the migration. Persistent=true runs the job at boot if its scheduled time passed while the machine was off, cron simply skips it, which is how monthly cleanup jobs silently never run on machines rebooted at the wrong moment. RandomizedDelaySec jitters the start so a fleet of servers doesn't hammer the backup target in the same second. Beyond that: output lands in journalctl -u name.service instead of lost mail, systemctl start name.service tests the job on demand without waiting for the schedule, and the service unit can carry resource limits, dependencies and a sandbox.
The two-file shape
A timer is always a pair: the .timer says when, the .service says what. They pair by name. Enable the timer, not the service, systemctl enable --now name.timer, and check the whole schedule with systemctl list-timers, which shows last and next run for every timer on the host: something cron never could tell you.