<p>I think that right now, the only human builds that are worth considering are hg19/GRCh37 as many data bases such as gnomAD still exclusively use this release. On the other hand, hg38/GRCh8 has many important fixes and the useful (but yet underused) feature of alternative loci.</p>

<p>Anything from older releases should be remapped to a more recent one.</p>

CC BY-SA 3.0
2017-05-31T23:34:31.387Z
2017-05-31T23:34:31.387Z
Manuel
<p>You could use liftOver which isn't always great.</p>

<p>Whenever I encounter this (especially NGS data readily available on the SRA), I often just get the raw files (e.g. fastqs) and re-align/re-map.</p>

<p>In your case (arrays) it may be a bit tough. Not impossible though, as I recently took some old yeast DNA/RNA microarray data and updated it to the newest genome. Just requires the right data (like DNA for normalization) and a good understanding of the entire process.</p>

<p>A last resort/alternative is to align your <strong>new</strong> data to the old genome to be able to make comparisons. This isn't ideal but works in cases where upgrading one source isn't possible or is a HUGE amount of time/effort. I've done this for a few fly experiments where all the available/previous data was done in dm3. All the old genomes can generally be found on <a href="http://archive.ensembl.org" rel="nofollow noreferrer">http://archive.ensembl.org</a> .</p>

CC BY-SA 3.0
2017-06-08T06:38:40.213Z
2017-06-08T06:38:40.213Z
story
<p>For mouse, I still see people using mm9/NCBI37 in high profile publications even though mm10/GRCm38 was released more than 5 years ago (2011). I personally don't think that's a great idea, but it's certainly valid according to the peer reviewers.</p>

<p>It also depends on your application. If you are working with coding regions (likely well known for a long time) or extracting genome-wide stats (enrichment at TSS, for example), the differences should be negligible.</p>

CC BY-SA 3.0
2017-06-08T00:09:09.243Z
2017-06-08T00:09:09.243Z
burger
<p>In my opinion, it is not very reliable. LiftOver is very limited in terms of transformations it can support. The <a href="https://genome.ucsc.edu/goldenpath/help/chain.html" rel="nofollow noreferrer">LiftOver Chain format</a> can capture only matching regions in the same order. It means that it can account for indels, but even simple structural variations become problematic.</p>

<p>For instance, when a newer assembly is available, it is usually a recommended practice to remap all the reads rather than transform the existing alignments.</p>

CC BY-SA 3.0
2017-05-31T21:03:50.680Z
2017-06-07T21:09:58.510Z
2017-06-07T21:09:58.510Z
Karel Břinda
<p>Is working with and relying on old genome builds still valid?</p>

<p>For example <a href="https://genome-euro.ucsc.edu/cgi-bin/hgGateway?db=hg18&amp;redirect=manual&amp;source=genome.ucsc.edu" rel="nofollow noreferrer">NCBI36/hg18</a>. Would results from papers based on old builds require <a href="https://genome.ucsc.edu/cgi-bin/hgLiftOver" rel="nofollow noreferrer">LiftOver</a> and re-analysis to be useful?</p>

<p>A bit of context, this is related to other post, where we have aCGH results based on old build: <a href="https://bioinformatics.stackexchange.com/q/316/131">How do I validate a single sample ArrayCGH result?</a></p>

CC BY-SA 3.0
2017-06-11T15:00:14.977Z
This will be probably dependent what type of analysis you have in your mind. In the end, all the data we generate today will be one day obsolete, but it does not necessary mean that all the conclusions are wrong. If you would be more specific about types of analysis you have in your mind (or concrete papers using hg18), maybe it would be easier to give a correct answer.
Kamil S Jaron
<human-genome><array-cgh><liftover>
Working with old genome builds
# Working with old genome builds

(Asked by: username_0 on 2017-05-31)

Is working with and relying on old genome builds still valid?

For example [NCBI36/hg18](https://genome-euro.ucsc.edu/cgi-bin/hgGateway?db=hg18&redirect=manual&source=genome.ucsc.edu). Would results from papers based on old builds require [LiftOver](https://genome.ucsc.edu/cgi-bin/hgLiftOver) and re-analysis to be useful?

A bit of context, this is related to other post, where we have aCGH results based on old build: [How do I validate a single sample ArrayCGH result?](https://bioinformatics.stackexchange.com/q/316/131)

**Tags:** human-genome, array-cgh, liftover
> **Comments:**
> **username_1**: This will be probably dependent what type of analysis you have in your mind. In the end, all the data we generate today will be one day obsolete, but it does not necessary mean that all the conclusions are wrong. If you would be more specific about types of analysis you have in your mind (or concrete papers using hg18), maybe it would be easier to give a correct answer.  

---

## 4 answers

### Answer by username_5 on 2017-05-31. Score: 8 | Accepted answer

In my opinion, it is not very reliable. LiftOver is very limited in terms of transformations it can support. The [LiftOver Chain format](https://genome.ucsc.edu/goldenpath/help/chain.html) can capture only matching regions in the same order. It means that it can account for indels, but even simple structural variations become problematic.

For instance, when a newer assembly is available, it is usually a recommended practice to remap all the reads rather than transform the existing alignments.


---

### Answer by username_2 on 2017-05-31. Score: 4

I think that right now, the only human builds that are worth considering are hg19/GRCh37 as many data bases such as gnomAD still exclusively use this release. On the other hand, hg38/GRCh8 has many important fixes and the useful (but yet underused) feature of alternative loci.

Anything from older releases should be remapped to a more recent one.


---

### Answer by username_3 on 2017-06-08. Score: 2

You could use liftOver which isn't always great.

Whenever I encounter this (especially NGS data readily available on the SRA), I often just get the raw files (e.g. fastqs) and re-align/re-map.

In your case (arrays) it may be a bit tough. Not impossible though, as I recently took some old yeast DNA/RNA microarray data and updated it to the newest genome. Just requires the right data (like DNA for normalization) and a good understanding of the entire process.

A last resort/alternative is to align your **new** data to the old genome to be able to make comparisons. This isn't ideal but works in cases where upgrading one source isn't possible or is a HUGE amount of time/effort. I've done this for a few fly experiments where all the available/previous data was done in dm3. All the old genomes can generally be found on <http://archive.ensembl.org> .


---

### Answer by username_4 on 2017-06-08. Score: 0

For mouse, I still see people using mm9/NCBI37 in high profile publications even though mm10/GRCm38 was released more than 5 years ago (2011). I personally don't think that's a great idea, but it's certainly valid according to the peer reviewers.

It also depends on your application. If you are working with coding regions (likely well known for a long time) or extracting genome-wide stats (enrichment at TSS, for example), the differences should be negligible.


---

