From time to time, one Evolution service bureau acquires a client or two from another bureau, or perhaps even acquires the whole other bureau, and databases have to be moved from one place to another, merging them into a single larger bureau.
I usually find out about this when a customer asks about renumbering the CL databases from one internal number to match the next available numbers on the other server, but this is not sufficient: if you only change the internal client numbers, there's a raft of other things that need this attention also: it's dangerous even though some customers tell me it "worked". They were just lucky.
Though renumbering the internal client numbers is straightforward (and iSystems had previously provided the SQL scripts for this), everything else has internal numbers too, and some of them also need adjusting. Things like Agencies, Banks, Users, Accountants, etc. all have internal numbers, and the Service Bureau references won't match at the new bureau.
Let's look at an example:
At the original bureau, an employee has a garnishment with Los Angeles County Child Support Services, and that agency might have an internal number of #123 inside the S_BUREAU database. You don't normally see this internal number, but it's how the client database gets at that SB item.
But if that CL database is moved to the new bureau—even with CL# renumbering—it's still going to point to SB_AGENCY #123, but there's very little chance the new bureau just happens to have the Los Angeles County Child Support Services with internal number #123.
Instead it's going to something else, maybe Agency #123 happens to be Upper Peoria Sanitation District, and that's probably not a good place to send a child support payment.
Yes, it's possible to mostly fix this by doing what amounts to a new-client setup on the client, touching all the items and fixing the references, but this is very tedious, highly error prone, and does not adjust audit history.
If you miss one, and if you're lucky, it will fail with an error that calls your attention to the matter, but if you're not lucky, it will quietly do the wrong thing. It's very hard to imagine getting it all right, all the time, and there are some fields you cannot directly fix by hand anyway.
Having random tax payments roll back because of un-migrated SB-reference fields is not pleasant, I'm told.
The main point of this post is to warn you against unwittingly volunteering for an emergency, but I can't help but put on my "Sales" hat by mentioning that I developed a system for Evolution client database migration almost a decade ago.
Many of you have experienced the famed Excel "Migration Worksheet" that contains the old→new internal number mappings that feed my migration software, and quite a few bureaus have migrated hundreds of clients overnight. This is almost impossible to do reliably by hand.
I've run dozens of successful migrations for quite a few bureaus, including for iSystems themselves (though not for Asure).
Email me if this kind of thing might be in your future; I can provide excellent references.