New team trying to figure out if data migration HAS to go in a user story

What does the Product Owner have to say about what constitutes value to stakeholders?

And, what does your Definition of "Done" state about the migrated data?  Is the Increment "potentially" shippable every Sprint?   If your Product Owner decided to release the Increment, would there be additional work needed if the data was not migrated, and would migrating it later cause additional integration effort? 

your first 50% is right !

50% of team says: when we create a new user story that has a new UI for the user, then we MUST have real live data in in the user story - thus it is one user story.  Create the UI, create the backend and migrate the data.

Scrum Guide : The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. 

Which definition of the user story satisfies this requirement from Scrum guide? Which one is usable and potentially releasable? The one with empty UI or a carefully crafted VERTICAL SLICE that has all technical layers incorporated into whatever small functionality you are developing that is potentially releasable?

Would you rather wait to now how the UI holds out with real data (technical debt!) later and redo the fix for all the UI whose shortcomings you never discovered because you never tested it with real data? Trust me unless your UI is tested with the real data you never know what design changes you have to make. I am certain that your 50% who proposed the right way to construct a user story (or whatever requirement form you used) is well aware of this.

There are instances where what the team thought were primary keys were not even needed when the real data came in and they had to concatenate two fields to create a unique primary key for their envisioned data structure. A simple change of date format could introduce an UI change.

The only exception is a POC project, where the you are not developing a working product but a proof of concept so the sponsor can fund the real project. In this case it is obvious what the goal is, a prototype without real data. What is the final intended outcome of your project? 

I agree with #2 The other 50% of the team says: We can create a workable UI that produces value for a user, the data does not necessarily have to be in the user story.  Therefore, Create workable UI is one users story.  Migrating and uploading actual data is a second user story.

I am a former developer and I have worked in operations to and now a scrum master and I see all sides here. I have had these exact same scenarios and the way I handled it is we were able to find a work around. The workaround was with minimal effort and a minimal data set the team was able to create mock data to display the functionality of a new UI.  If you can do that with a large enough data set that will show the functionality get acceptance, then I'd think you'd be OK.  get the PO's buy in on it 

The data migration the way I see it is a integration task. I know up for debate. 

Since you are not releasing live right away you would have time if it is several sprints to figure out the right time\path\ to get that data migrated. Data Migration is at least to me can be done later.  

We are all of course high level guessing of what we think your PO will except  that's why you see the differing opinions. 

An important note is that none of these sprints will be going live.  They DO get accepted by the user, but they do not offer any value to the user until numerous sprints are accomplished.

Based on the text above I would say that if you are not put the new system "on Live", just do the data migration near the "Go Live" of the system. That because if you migrate the data but do not put the system "on live" you will need to review/migrate the data all over again when you put the system "on live" because the data may be changed since the last time you migrated because the old system still running.

Now if you want to change the strategy and you have a way relase the new features of the new system and you "Go Live" with only that feature to the user/client piece by pice and they will start to use that pice the new system and the other features is running in the old one(the 2 systems coexist ), I go with the option #1, do the data migration in the story, so you can deliver the feature and the data, so thats bring more value to the Client/User and they can start to use thats the new system. The only problem here that sometimes the user don't want to live with 2 system, I know because my team tried to do that one time and the user start to complain that he needed to use 2 system, 2 different front-end and etc, so in that case the tip is to always know the final user expectations.

If you can't do what I say above(The old system coexist with the new one done piece by piece) I agree with #2, so you can deliver the new features in production and only when you had something like a MVP and "Go Live", you do the migration and release to the Client/User the new system features and stops to use the old system.

How about making a copy of production database and just clearing all sensitive data? Then you could point new UI to that test database and be pretty close to prod (not including actual traffic loads).