# Migration testing: System Testing vs System Integration Testing **URL:** \ **Category:** Archive\ **Created:** [18 July 2021 15:41 UTC](https://club.ministryoftesting.com/t/migration-testing-system-testing-vs-system-integration-testing/52069 "2021-07-18T15:41:41Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![cs0roc](https://avatars.discourse-cdn.com/v4/letter/c/f6c823/32.png) [@cs0roc](https://club.ministryoftesting.com/u/cs0roc)\ **Post date:** [18 July 2021 15:41 UTC](https://club.ministryoftesting.com/t/migration-testing-system-testing-vs-system-integration-testing/52069/1 "2021-07-18T15:41:41Z")
Hi there, Please can people give me their throughs on distinction between “system testing” versus “system integration testing” within the context of testing data migration? Sorry, not got much context to share! Thanks, H. ---
**Author:** ![bobs](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/bobs/32/8768_2.png) [@bobs](https://club.ministryoftesting.com/u/bobs)\ **Post date:** [18 July 2021 16:03 UTC](https://club.ministryoftesting.com/t/migration-testing-system-testing-vs-system-integration-testing/52069/2 "2021-07-18T16:03:37Z")
A problem with data bugs, e.g. data migration bugs, is that it’s not always obvious where they will show up / cause a problem. In a data-backed web app, bad data might cause some back-end code to fail, or some front-end code to fail. So you will probably need system testing, rather than e.g. just testing via an API, to test the data. There is an interface between the front end and back end of a web app, so you could describe this as integration testing. However, there might be bigger, more important and riskier interfaces around, and the testing of these is what might be referred to as system integration testing. For instance, if the system under test is actually a collection of systems (e.g. micro-services) and you add customers to the customer system via the data migration, has the same / equivalent data also been added to the debt chasing system, the payment system, the order history system etc? Tests would need to make sure they’re testing the conversation across these interfaces. Then there are major interfaces where you don’t control what’s on one side e.g. when talking to a bank (assuming your code is not also that bank, e.g. an online shop). Has the data in the part of the system under test that talks to the bank been migrated such that the necessary conversations can happen correctly? ---
**Author:** ![c32hedge](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/c32hedge/32/9126_2.png) [@c32hedge](https://club.ministryoftesting.com/u/c32hedge)\ **Post date:** [19 July 2021 18:43 UTC](https://club.ministryoftesting.com/t/migration-testing-system-testing-vs-system-integration-testing/52069/3 "2021-07-19T18:43:13Z")
I’ve noticed a general tendency in our industry to create rather arbitrary buckets (e.g. “API testing” vs “UI testing”, “end to end testing” vs “integration testing vs “system testing”) and then split hairs over which buckets to put which tests in. Not to disparage this particular question, that’s just my general observation. Maybe it’s partly the fault of ISTQB or something. Personally, I don’t think there’s value in making a distinction between “system testing” and “system integration testing”, and I actually have no idea what that distinction is if someone has made it 😱. What I think would be much _more_ valuable is to take a step back and consider what kind of problems you’re looking for, what risks you’re concerned about and what you want to test. After you know that, it may be useful to bucket things based on _how_ it makes sense to test different things on your list. I think @bobs answer did a great job of describing that aspect. ---
**Author:** ![theology](https://avatars.discourse-cdn.com/v4/letter/t/9fc29f/32.png) [@theology](https://club.ministryoftesting.com/u/theology)\ **Post date:** [23 July 2021 05:53 UTC](https://club.ministryoftesting.com/t/migration-testing-system-testing-vs-system-integration-testing/52069/4 "2021-07-23T05:53:37Z")
@cs0roc not sure , if you are looking something like this > **[System Testing and System Integration Testing - Software Testing](https://www.h2kinfosys.com/blog/system-testing-system-integration-testing/)** > > In this article, the system testing and system integration testing are described. The system testing is performed by the QA team to identify the defects and verify the software compliance with client requirements without involving the programming... ---
**Author:** ![vishaldutt](https://avatars.discourse-cdn.com/v4/letter/v/5f9b8f/32.png) [@vishaldutt](https://club.ministryoftesting.com/u/vishaldutt)\ **Post date:** [10 November 2021 07:53 UTC](https://club.ministryoftesting.com/t/migration-testing-system-testing-vs-system-integration-testing/52069/5 "2021-11-10T07:53:20Z")
Data migration is the process of moving data from one location to another, one format to another, or one application to another. The data migration activity starts with the data backed up on the tape, so that, at any time, the legacy system can be restored. All the scripts and steps must be documented correctly without any ambiguity. To note down the actual time taken for migration from the starting of migration till successful restoration of the system is one of the test cases to be executed and so that the ‘Time taken to migrate the system’ needs to be recorded in the final test report which will be delivered as part of Migration test results and this information will be useful during the production launch. The downtime recorded in the test environment is extrapolated to calculate the approximate downtime in the live system. It is on the legacy system where the Migration activity will be carried out. During the data migration testing, all the components of the environment will usually be brought down and removed from the network to carry out the Migration activities. That’s why it is important to note the ‘Downtime’ required for the Migration test. Once the application is successfully migrated, then data migration testing comes into the picture. Here end-to-end **System testing** is performed in the testing environment. Testers execute identified test cases, test scenarios, use cases with legacy data as well as a new set of data. As per the testers, it all means that the application has to be tested thoroughly end-to-end along with migration from the existing system to the new system successfully. System testing has to be performed in this case with all the data, which are used in an old application and the new data as well. Existing functionality needs to be verified along with the new/updated functionality. So, data migration testing includes testing with old data, new data or combination of the both, old features (unchanged features), and the new features. The Integration test cases can be used to verify the interface between the components should be extensively tested, as the data should not be modified, lost, and corrupted when it is going through components.