I will first share a little anecdote. I have one of those really cheap USBasp programmers that I bought for $3 on eBay on a sale. It's a bit crude, but had worked well up until building a new project, when it stopped recognizing the AVR on the board it was connected to. It turned out several of the programming connections had no continuity from end to end. After a lot of head scratching and continuity testing, it turned out that the ribbon cable connector that came with the programmer did not make contact with the pins on the programming header on my project board for whatever reason, I'm assuming poor tolerances. I still had continuity when I inserted a wire into the connector, so the problem was with the male-female connection, not in the crimp connection. I replaced it with another 10 way ribbon cable and everything worked again.
An oscilloscope would of course be useful for a lot of things here, if you have access to one. For example checking if the clock is oscillating in this case.
Mandatory double check: Are all the programming pins still in the same places on the new board?
What are you using for programming the chip? If you are using avrdude with an ISP programmer of some sort, try giving just the avrdude command with no programming (-U) switches just to see if the chip responds at all.
Eg: avrdude -c programmer_name -p m328p
You should see device signature and fuses ok. If even that fails to access the chip, try adding the flag -B 1 to set the bit clock (communication speed) really low to see if that makes a difference. If you can at least get that to work, we have something to work from. The working theory here is that the fuses somehow got set to the internal RC oscillator instead of the external one and that the chip is now running at whatever low speed the RC oscillator runs at, so the programmer's SPI speed is too fast for the chip and the programming fails completely.
I doubt that would be the case of the problem in this case, but one possibility is voltage overshoot on startup on the Vcc rail.