question

One way or the other, your players will have accounts in PlayFab, since they need to log in to get a session ticket (which is used for everything else). I'd recommend moving everything into our system, since that'll make sure you have all the details in there for things like segmentation.

To "migrate" players, it'll depend upon what you have in your current backend system - specifically, whether you have an authoritative server. The first step, obviously, is to create the user accounts. What I'd recommend is to add the code to log into PlayFab (and move over the data - see below for that) to your game, so that the next time the player logs in after the update, they create the PlayFab account. That way, newly created PlayFab accounts will have the correct geolocation info for the accounts (since we use the IP Address of the caller to determine that).

After you've been doing that for a while (at least a month, I'd say), then you can choose to either forget about all the players that haven't logged in since your update (with most games, if they haven't played in a month, it's unlikely they'll be back), or you could create accounts for them via a script or tool you write locally. For that, first get the list of all players via https://api.playfab.com/documentation/server/method/GetPlayersInSegment (use the "All players" segment). You can then use that to check against your old database, to see who doesn't have an account. For those players, you would use the appropriate Login... API call to create an account for them. Make sure to throttle that, so that you're not calling it more than once per second, so that you don't get throttled.

Now, for the player's data, stats, inventory, etc., that's where the question of whether you have an authoritative server comes in. If you do, then on the player's first sign-in, you would have the client request that the data be moved. Basically, you would have a function in your existing server solution that uses the Server API to update the player's account with their data, etc. Now, if it's a lot of data, stats, inventory items, etc., you will need to throttle the rate at which you update that player account in PlayFab, to make sure you don't run into any issues. Also, you may want to consider aggregating some of your data into fewer, larger keys if you have a lot of key/value pairs for your player data in your existing system.

If you don't have any existing backend logic, that means your client has been fully authoritative up to now. So you'll need to decide how much you want to continue to allow that (since it makes it easy to cheat, we tend to advise against it). But for the first login, you'll want to have the player submit a data blob that describes the account up to that point. If you're moving to use custom game servers, you can have that server do the next part - otherwise, you'd use Cloud Script, and have the client first submit the data, then periodically pump an update handler until the account has completed the update process (in this case, only call it once every 5 seconds or so).

What that means is that you'd write the player's "this is the state of my player/game" to player internal data, and first check it for obvious signs of cheating (you could just give them a starting account at that point, say "too bad you cheated", and call it done). If they haven't, update the player account in PlayFab with what you can, given a reasonable throttling rate for the data, inventory, stats, etc. With a custom game server, that'll obviously be simpler, but with Cloud Script, you could have the script do some work, then exit (and as stated, have the client pump that call again after a delay). Once everything is updated, set a flag on the player account to indicate that, so that any attempt to call that functionality again immediately exits, rather than doing any of that logic.