Difference between revisions of "Merging Existing Systems"
Line 19: | Line 19: | ||
* Project names, User names, and field options are key examples of unique identifiers within text. | * Project names, User names, and field options are key examples of unique identifiers within text. | ||
− | Some of the names within lists can be merged. For example, if both systems have an accommodation type called | + | Some of the names within lists can be merged. For example, if both systems have an accommodation type called "private rented", the one merged system can use "private rented". If both systems have similar, yet not identical items, it is advised the item names are aligned before the merge if they serve the same recording purpose. E.g if one item is "British (White)" and the other is "White British". |
We can also make relevant changes to User names, should two systems have a user of the same name. In this instance, we can add a unique identifier to each of the user names, in order to differentiate them. For example, if two users go by the name "John Smith", the new system will have a "John Smith Cardiff" and "John Smith Bristol". | We can also make relevant changes to User names, should two systems have a user of the same name. In this instance, we can add a unique identifier to each of the user names, in order to differentiate them. For example, if two users go by the name "John Smith", the new system will have a "John Smith Cardiff" and "John Smith Bristol". |
Revision as of 12:28, 27 January 2020
When two organisations merge, if they both use Charitylog or Crossdata, they may want to merge their systems together into a single system.
The purpose of this page is to provide a general overview of the merge process.
If you are considering merging and would like to make any further enquiries, please call the Dizions office on 0333 222 5957, and request to speak to a member of our Data team.
Merging Process
Our priority at Dizions is ensuring data integrity. Our data team will predominantly manage this for you, and ensure all data is handled appropriately.
A notable example of this is the handling of "unique identifiers". Unique identifiers are used in Charitylog and Crossdata systems. Inevitably you will have the same referral or client ID number on your system as the system you will be merging with.
- Referral ID numbers and client ID numbers are key examples of numerical unique identifiers.
The solution to this when merging systems is to increment the ID numbers of one system, whilst retaining the ID numbers on the other. This would typically be done by adding simple values to the ID numbers. For example, if the first system has 560 clients, we may add 10,000 to the ID's in the second system. This means client 56 in the first system would remain as 56, and client 56 in the second system would be 10056. It is also possible for both sets of ID numbers to be incremented, should you wish. Making the first set of ID's 10056, and the second set of ID's 20056. This can help Users distinguish between older and more recent ID's.
- Project names, User names, and field options are key examples of unique identifiers within text.
Some of the names within lists can be merged. For example, if both systems have an accommodation type called "private rented", the one merged system can use "private rented". If both systems have similar, yet not identical items, it is advised the item names are aligned before the merge if they serve the same recording purpose. E.g if one item is "British (White)" and the other is "White British".
We can also make relevant changes to User names, should two systems have a user of the same name. In this instance, we can add a unique identifier to each of the user names, in order to differentiate them. For example, if two users go by the name "John Smith", the new system will have a "John Smith Cardiff" and "John Smith Bristol".
A test migration will be conducted before any work is carried out on the live system. This will not require any system downtime, and it will allow you to review the work complete within a test environment.
When you are ready for the live migration, one working day of downtime will be required. This date will be arranged between yourself and our data team.