The requirement for deployment is that:
1) the timer job I created only interact with the site it is being deployed for. Note that it can fire on everything else, but it should know fairly instantaneously it is in the wrong spot and not continue.
2) If they decided to migrate the site at some point, it needs to work in a manner where we don't have to redeploy the timer job after some modification. It should work as is.
The first item, I'm not 100% sure what to do with that. Thus far, I've changed it so that it is scoped a little less globally, but if you have /sites/sitea, /sites/siteb, I could see it happening. The recommendation I received is that if we add a custom list (a settings-ish one), we could assign a key there and make sure it matches with the internal hard coded one. That could work, but seems to be a deployment nightmare (could be wrong, new to SharePoint).
The second item is going to require a (small) bit of modification on my part. Currently, the way I've been obtaining Lists to interact with has been by:
SPList list = web.GetList(CONSTANTS.SITE + "Lists/ListName");
I know the constant will need to be changed (web.Url?), but I think that may be all that is needed. For getting SPWeb/SPSite, I tend to go with the generic Properties["site-id/web-id"] method in the SPJobDefinition and in feature Event Receivers and using properties.Feature.Parent as SPWeb. For typical Event Receivers, properties.OpenSite(). Basically, no hard coding there.