MSA to MSA level migration data

Hello, I am working on utilizing ipums data to find out where domestic migrants come from/ go to with regards to arizona and MSA’s within. I am having a hard time using the online analysis tool in order to find this information, and I was wondering if anyone could help point me in a direction to learn more.

there are a few issues that I have seen so far, primarily being that these data don’t seem to be available from the early 2010’s onward. are they simply not released currently? I’d like to find data that pertains to 2021 or 2022 migration

without direct msa to msa level data, would it be possible to somehow manipulate the puma level data in order to find something similar to msa to msa? the issue with this seems to be that the puma’s have quite arbitrary boundaries (pima and pinal counties are combined, despite pima being its own msa and pinal being closer in activity to the phoenix msa)

if not, would there be any way to construct county to county level data? it also seems like its unavailable, but I’m not sure if I am simply doing a poor job of finding it. (county level would be preferred to puma level)

any help would be greatly appreciated in this manner

The ACS Public Use Microdata Sample reports respondents’ place of residence 1 year ago in terms of their Migration Public Use Microdata Area (MIGPUMA1) and State/Country (MIGPLAC1). In cases where Migration PUMA boundaries closely align with those of a metropolitan area, we identify the metro in MIGMET131. You can read more about the protocol used in this assignment on the MIGMET131 variable page (see previous link). MIGMET131 is one of many variables that are not available for analysis in the online tool; you will need to request a customized extract with this variable to run a MSA-to-MSA migration analysis.

You might alternatively run a State-to-MSA or MIGPUMA-to-MSA migration analysis using the online tool since MIGPUMA1 and MIGPLAC1 are both available through the system. To do so, you will want to cross-tabulate one of these variables with MET2013 (current metro area of residence). MET2013 uses a similar protocol to MIGMET131 in assigning households to metro areas. Below is an example of a State-to-MSA migration analysis for the period 2018-2022 using the online tool. This will report the percent of the population in each of Arizona’s metro areas who did not move in the past year (MIGPLAC1 = 0) and the percent that moved from each state. The filter STATEFIP = 4 restricts the analysis to respondents who resided in Arizona at the time of the survey. MIGPLAC1 = 4 identifies respondents who had moved residences in the past year, but remained in Arizona. They may have moved across the state or stayed within the same metro area. An MSA-to-MSA level analysis would be required to determine this.




The assignment protocol for MIGMET131 is imperfect in cases where MIGPUMA boundaries do not perfectly coincide with metro area borders. This is also true for MET2013, which uses PUMA boundaries to assign households to their current metro of residence. The protocol assigns all households in a PUMA (MIGPUMA) to a metro area if the majority of the households in that PUMA (MIGPUMA) are located within that metro. This results in errors of omission (residents of a MSA who are not identified as residents) and errors of commission (non-residents who are identified as residents). These errors are identified in the MET2013 delineation files (MIGMET131 variable page) and are reported in MET2013ERR (MIGMET13ERR). IPUMS USA will not identify the current metro area (metro area of previous residence) where this protocol yields a sum of match errors of 15% or more. An added complication is that a new PUMA and Migration PUMA map is issued roughly every 10 years (in 2005, 2012, and 2022), which can cause a significant change in a metro area’s omission/commission errors. As a result of the revision in MIGPUMAs in 2022, respondents who moved from the Tucson metro area are not identified starting in 2022.

Some users may be concerned with the amount of potential measurement error that is created when compounding errors in MET2013 identification with errors in MIGMET131. This is often a compromise that users of microdata have to make in exchange for the flexibility of multivariate analysis. If you determine that the cost of this measurement error in the microdata is greater than the benefit of using microdata, then you might consider using the aggregate metro-to-metro migration flow tables released by the Census Bureau.

1 Like