Difference between revisions of "Merging Existing Systems"

From Charitylog Manual
Jump to: navigation, search
Line 15: Line 15:
  
 
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 numbers 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.
 
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 numbers 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. This could mean making the first set of ID's 10056, and the second set of ID's 20056. This can help Users distinguish between old and new ID's.
+
It is also possible for both sets of ID numbers to be incremented, should you wish. This could mean making the first set of ID's 10056, and the second set of ID's 20056. This can help users distinguish between old and new ID's.
  
 
* 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.

Revision as of 14:58, 27 January 2020

We recognise there is sometimes a need for some Charitylog/Crossdata systems to be merged into one system.

The purpose of this page is to provide a general overview of the merge process.

If you are considering merging your system 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 and ensuring all data is handled appropriately. Our data team are able to help you with this.

A notable example of this is the handling of "unique identifiers". Unique identifiers are used within 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 numbers 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. This could mean making the first set of ID's 10056, and the second set of ID's 20056. This can help users distinguish between old and new 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, both systems may have an accommodation type of "private rented", which can be formed into one option. 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", it would make sense to keep the options aligned.

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.