Sometimes it’s necessary to split a Datix system. In my case we were splitting a single existing system into two, to match a corresponding corporate re-arrangement whereby one company was dividing into two (with separate branding and domain names, etc). While there are some obvious steps, and some which will depend on the exact nature of your split, I thought it might be helpful to jot down the not-so-obvious issues I ran into. All of this relates to v14 of DatixWeb.

The basic premise here is that we are going to take the existing system, A, which currently contains all data, and copy it to create a new system, B. We will then delete half of the data from A and half from B, so that each retains only the information relevant to its new area of operation. System A continues to operate as it always has done, so you only need to fiddle with connection settings and the like in System B. Your new database and new Rich Client / DatixWeb environments may well be on the existing server(s), or on an entirely different one; either is fine.

I don’t want to go into all of the gory details here, and I would strongly suggest enlisting the help of Datix to do this (we did), rather than trying to sort it out yourself. However, the main steps are:

1. BACK EVERYTHING UP! That includes the database, the DatixWeb environment(s) including any test ones, and the network document store.
2. Don’t blame me if it all goes wrong. 😉
3. Back up database A. Restore it as a new database, X.
4. Copy DatixWeb environment B. Paste it as a new DatixWeb environment, Y.
5. Copy the Datix network document store, C. Paste it as a new folder, Z.
6. Update the DatixConfig.php file in environment Y so that it points to database X. If you don’t, both environments will still be amending the original database, A!
7. Set up a new Datix Rich Client shortcut so that it points to database X. Don’t forget that you’ll need to create a new ODBC source to point at the new database, X, and will also then need to update the Global Parameters to point to the right locations for Documents, reports, etc., Z.
8. In the new system:
   • update the outgoing email (SMTP) server details to ensure that the new system is trying to send emails through the correct server;
   • update the Datix Admin email address:
9. In both systems as required:
   1. Add/remove domain(s) from the “permitted domains” list in DatixWeb configuration.
   2. Deactive and/or hide un-needed data using ‘Batch update‘ – we’ll delete it later, once we’re sure nothing awful has happened:
      • Deactivate un-needed codes by setting the ‘Active‘ column to ‘N‘. Easier in the Rich Client than DatixWeb because you can just whiz down the editing table very quickly.
      • Disable un-needed user accounts by setting the ‘Closed date‘ to today’s date.
      • Search for open incidents, complaints, etc. no longer required in each system, and use a batch update to set the “Approval Status” to “Rejected” for them all. This is particularly important because if you send reminder emails using the “Overdue email notification” function while the records are open, Datix will still send emails to the closed user accounts, resulting in all kinds of confusion.
   3. If you have any URLs in customised DatixWeb email templates, update them. This might include hard-coded links to Datix records, or links to policies/procedures.
   4. Similarly, update form designs (DIF1, etc.) to account for any new URLs that apply.
   5. Once you’re comfortable that the system is working effectively with lots of the old data closed/disabled then you can eventually delete it:
      • Delete un-needed user accou nts.
      • Delete un-needed documents from the file share. HOW?
      • Delete un-needed data from every module. Don’t forget that this includes the support modules like Contacts, Equipment and Actions, as well as all of the ‘main’ modules.
        Note that you can remove records by doing a search and using the “Batch Delete” function – this is the method recommended by Datix. While those of you who have been around a while may remember when this was a bit flaky, it’s now (v14) quite robust. I deleted our incidents in batches of 10,000 because doing any more takes ages and I started to worry that something had broken each time!
      • Delete un-needed codes. DO NOT delete them before you’ve searched for all of the module data you need to delete as described above – if you delete the codes, then you won’t be able to easily search using them (obviously you could just type them in manually, but who has all of their codes memorised?!).
      • Delete user security Profiles and Groups which are no longer needed.
      • Delete user-generated reports which are no longer needed.